<kbeckmann>
Bird|otherbox: I don't have any experience in compliance testing and don't own any proper EMC testing equipment. At hand I have a PlutoSDR, LimeSDR and a nanoVNA. Maybe a near field probe with an SDR can show me something useful?
<kbeckmann>
To give some context, I'm building a development board using the Lattice ECP5 FPGA. On the board there's an i.MX RT 1010 MCU, a bunch of DCDC converters that might be a bit noisy and some psram. A user could write nasty gateware that sends out radio signals that can be picked up over 5 meter away with a radio receiver but I'm not sure how to protect against that..
<Bird|otherbox>
kbeckmann, you're better off with a far-field measurement first, using a spectrum analyzer (maybe one of your SDR boards could be used as one if the F/E was broadbanded enough?), an outdoor range of some sort (park space, if you don't have a big enough yard for the measurements) and a suitable antenna (usually, log-periodics are good. I wonder if a TV antenna would sort-of-work?)
<kbeckmann>
the lime is pretty broadband, but i could do a slow sweep and aggregate the result i guess.
<kbeckmann>
is the idea of being outside from a distance a way to get a more precise average rf emission figure?
<kbeckmann>
when it comes to development boards like this, what are you supposed to measure? just the idle state? since a user can put any firmware and gateware on it, it could have a very different noise figures depending on what is running.
OmniMancer1 has quit [Ping timeout: 240 seconds]
OmniMancer has joined ##openfpga
<Bird|otherbox>
kbeckmann, the idea is to get a "pass/fail" wideband measurement overall
<Bird|otherbox>
then take your design back to the lab and use the nearfield stuff to zero in on *where* the RF "hotspots" are
<kbeckmann>
ah, i see
<Bird|otherbox>
kbeckmann, good point re: FW and gateware, and a good word for a FPGA program too :D
Degi has quit [Ping timeout: 264 seconds]
Degi has joined ##openfpga
parport0 has quit [Ping timeout: 265 seconds]
Bike has quit [Quit: leaving]
genii has quit [Quit: See you soon.]
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 260 seconds]
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 256 seconds]
<lain>
am I correct in understanding that nmigen will silently truncate if I assign an N bit signal to a <N bit signal?
<tpw_rules>
correct
<lain>
I wonder if there's any linters or any way to make it alert me to that, because I'd rather that be an explicit operation for the sake of correctness :/
futarisIRCcloud has joined ##openfpga
emeb_mac has quit [Ping timeout: 264 seconds]
emeb_mac has joined ##openfpga
peepsalot has quit [Ping timeout: 246 seconds]
peepsalot has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
hitomi2502 has joined ##openfpga
OmniMancer1 has joined ##openfpga
OmniMancer has quit [Ping timeout: 256 seconds]
Asu has joined ##openfpga
OmniMancer has joined ##openfpga
OmniMancer1 has quit [Ping timeout: 258 seconds]
mumptai_ has quit [Quit: Verlassend]
mumptai has joined ##openfpga
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined ##openfpga
<Lofty>
lain: it's planned, to my knowledge
jemk has quit [Remote host closed the connection]
<Lofty>
The main obstacle being that assignment to a Signal also extends
jemk has joined ##openfpga
<Lofty>
So when nMigen gets an extension/truncation operator, then it'll be possible to lint on that kind of thing
<whitequark>
Lofty is correct
<Lofty>
^.^;;
<lain>
anyone have good a good resource (video, book, etc) for learning SystemVerilog for synthesis?
<Lofty>
AIUI SV doesn't actually have a standard synthesis subset
<whitequark>
yep
<whitequark>
the behavior of always_ff is unspecified, for example
<whitequark>
and failing synthesis if a latch is inferred is actually illegal according to the standard (!)
<lain>
why is everything garbage in this industry
<whitequark>
stockholm syndrome leads to people not demanding better tools
<whitequark>
"i suffered learning verilog for years, now you will suffer too"
<Lofty>
Also, I don't know why you were expecting good things out of something that calls itself a Verilog extension
<lain>
nMigen has a lot of nice features, but I don't think I can stand the added abstraction layer (writing code that generates HDL, rather than just describing the RTL directly)
<whitequark>
nmigen is lower on the abstraction ladder than verilog, actually
<whitequark>
since it doesn't try to infer anything
<whitequark>
it also only generates HDL if you're using a proprietary toolchain; if you use yosys, it works exactly like any other HDL frontend, it's just written in python
<whitequark>
that said, it's perfectly fine to not like it for whichever subjective reasons you have :p
<lain>
I mean, I'm interested in convincing arguments as to why nmigen is superior
<lambda>
lain: ever tried VHDL?
<whitequark>
I'm not sure I'd describe it as "superior", but there were a few guiding principles
<lambda>
it has its own problems, obviously, but at least it has types
<whitequark>
first, it's a language specifically for description of synchronous logic, and not for simulation/verification
<lain>
lambda: I use VHDL normally, I am attempting to upgrade
<whitequark>
second, it doesn't ever try to guess what you wanted to get ("infer"). if you want an FF, you describe an FF. if you want a memory port with specific geometry, you ask for that
<lain>
my biggest problem with VHDL is tool support, particularly in the open-source space. GHDL is fine but it's lacking support for a variety of things I use or would like to use
<whitequark>
third, it doesn't try to invent its own barely-useful meta-language for generating logic, it uses python
<whitequark>
that's about it
<whitequark>
it's trying to be both simpler and more reliable than verilog so that you can use it as a foundation for building more complex things
<lambda>
lain: ah, alright - Tristan is always hard at work, but such a one-man show just isn't very quick no matter how you look at it
<Lofty>
whitequark: fourth: it aims to always give the correct result
<lambda>
lain: you have opened issues for those things, right? ;)
<lain>
lambda: for years now, yes
<whitequark>
there's also some added niceties, like signed arithmetics working like you'd expect it to work
<lain>
so torn :3
<whitequark>
the python stuff is not for everyone, i agree that much. i mean, i don't even like python much myself
<whitequark>
it's just very practical to use it
<whitequark>
compared to, say, scala
<lain>
my main complaint at this point is the abstraction of writing code that generates logic, rather than describing logic directly -- I wonder if it gets easier to read nmigen code as you get used to it
<whitequark>
can you describe why you find verilog easier to read? it has `generate` statements too
<lain>
mostly just the syntax is more obtuse: "self.a.eq(self.b | self.c)" vs for example "a <= b or c;"
<whitequark>
ahh
<whitequark>
yeah, you get used to it
<lain>
I mean it's not the end of the world, it's just more convoluted than I'd like. but there's a lot of power gained with the way nmigen works so...
<lain>
I think I'll give it a shot for the next think I write for fun and see how it goes :3
<whitequark>
cool!
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale has joined ##openfpga
<cr1901_modern>
I still get a bit tripped up by sync and comb statements being enclosed by if-blocks, rather than the other way around. But I know that's a deliberate design decision.
seraxis has quit [Ping timeout: 260 seconds]
rqou has quit [Ping timeout: 272 seconds]
rqou has joined ##openfpga
seraxis has joined ##openfpga
<lain>
thanks all for indulging me
Lofty has quit [Ping timeout: 240 seconds]
Bike has joined ##openfpga
mumptai has quit [Remote host closed the connection]
<keesj>
migen really only works it you understand what is behind (e.g. have an understanding of VHDL or verilog) and can manipluate the system to generate what you want. OOTH is is pretty good at system level stuff and portability ,, chose your poison wisely . I am ratter happy about the https://github.com/enjoy-digital/litex community and the good cooperation happening, amount of active users. This is what gives
<keesj>
me confidence (and where I find working examples of say a fully working arty board inc ddr and ethernet
<keesj>
if I then need to add a little logic.. it might not be that bad of a choice
<whitequark>
keesj: i'd say you have to have an understanding of synchronous logic, like with vhdl or verilog
<whitequark>
nmigen at least no longer relies on going through verilog, though proprietary flows still need that
<agg>
right, my experience was understanding what the fpga was doing and how nmigen maps to it was very helpful but i didn't need or want to know anything about verilog for it
<tnt>
it's a HDL ... not a HLS. You have to know what you're trying to describe.
<whitequark>
yep
<agg>
i already had python experience before doing hdl so being able to metaprogram it in python was a huge advantage compared to verilog
<agg>
the metaprogramming is so so effective
hitomi2502 is now known as hitomi2500
hitomi2500 has quit [Quit: Nettalk6 - www.ntalk.de]
hitomi2500 has joined ##openfpga
genii has joined ##openfpga
sgstair_ has joined ##openfpga
emilazy_ has joined ##openfpga
Asuu has joined ##openfpga
genii_ has joined ##openfpga
Richard_Simmons2 has joined ##openfpga
seraxis has quit [Ping timeout: 256 seconds]
specing_ has joined ##openfpga
sgstair has quit [Read error: Connection reset by peer]
emilazy has quit [Write error: Connection reset by peer]
Lord_Nightmare has quit [Remote host closed the connection]
genii has quit [Remote host closed the connection]
Asu has quit [Remote host closed the connection]
specing has quit [Ping timeout: 265 seconds]
emilazy_ is now known as emilazy
Lord_Nightmare2 has joined ##openfpga
futarisIRCcloud has quit [Ping timeout: 256 seconds]
Richard_Simmons has quit [Ping timeout: 256 seconds]
levi has quit [Ping timeout: 256 seconds]
rohitksingh has quit [Ping timeout: 256 seconds]
cblam has quit [Ping timeout: 256 seconds]
_florent_ has quit [Ping timeout: 256 seconds]
specing_ is now known as specing
Lord_Nightmare2 is now known as Lord_Nightmare
_florent_ has joined ##openfpga
cblam has joined ##openfpga
levi has joined ##openfpga
futarisIRCcloud has joined ##openfpga
seraxis has joined ##openfpga
rohitksingh has joined ##openfpga
jfcaron has joined ##openfpga
ZirconiumX has joined ##openfpga
ZirconiumX is now known as Lofty
genii_ is now known as genii
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
emeb has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
hitomi2500 has quit [Quit: Nettalk6 - www.ntalk.de]
indefini[m] has quit [Quit: Idle for 30+ days]
ayjay_t has joined ##openfpga
<ayjay_t>
did anyone reverse engineer the dialog semiconductor greenpak bitstream?
<whitequark>
it's documented in the datasheet.
<ayjay_t>
oh look at that it's right there
<ayjay_t>
thats so exciting
<whitequark>
gp4par was the first ever OSS P&R tool
<ayjay_t>
was the company was pretty cooperative?
<ayjay_t>
sorry that was poorly worded
<whitequark>
very much so
<whitequark>
well, it used to be silego
<whitequark>
no idea how dialog is like
<ayjay_t>
i'd like to probe and find out
<ayjay_t>
if i use this in a commercial product i want a place to make a donation to the toolset/developers
<whitequark>
azonenberg did gp4par
<whitequark>
i reverse-engineered their programming tool
<azonenberg>
ayjay_t: we have a working toolchain, or at least we did (i havent touched it in a while so hopefully it hasnt bitrotted) for the greenpak4 family
<azonenberg>
slg46140 and slg4662x
<azonenberg>
support for newer devices was never added due to lack of time on my part
<ayjay_t>
this is my intro to FPGAs and i'm going to be buying both their development suite and setting up the open source toolchain. its a startup company so someone else will inherit it and i'd like to start them off on your work. i'd also like to make like a $150 donation if it's convenient.
<ayjay_t>
but anyway thanks for helping me and the work
<daveshah>
this is the one time a year that something strictly on-topic (the original openfpga project) gets posted on this channel :)
<ayjay_t>
twitter in the streets, irc in the datasheets
<Zorix>
I was reading.. I think last week.. that lattice is trying to fight back against the bitstream documentation going on with their chips by altering license and legal terms
<daveshah>
They aren't any more :)
<Zorix>
oh?
<daveshah>
they removed the problematic term and apologised
<Zorix>
now if only they help the projects they could establish themselves more as a first class manufacturer in open tools
<Lofty>
It's probably a lot easier for them legally to let us deal with things ourselves
<Zorix>
likely yeah
<Hoernchen>
cosidering how protective most companies are that pullback is already far more than i expected
<Zorix>
me too
<emeb>
lol - playing around with an ice40UP5k, using the internal HFOSC with divider parameter set to 0b10. Output freq should be 12MHz +/-10% or so (ie 10.8-13.2MHz). I'm seeing 19.3MHz.
<emeb>
suppose I could play with the unofficial TRIM? lines to see what happens.
<tnt>
emeb: that's definitely not normal.
<tnt>
in my testing, it was really not all that far off.
<emeb>
tnt: yeah, kinda surprised. I've used these before and they weren't this bad.
<emeb>
super jittery, but usually pretty close to spec
<tnt>
What board is that on ?
<emeb>
this is a personal board
<tnt>
and the 2v5 rail is powered ?
<emeb>
Yes, but interestingly enough the diode drop from 3.3V to VPP is only about 0.2V. That might explain why the osc is running fast.
<tnt>
No, that shouldn't matter, you can wire it up to 3v3 directly too.
<tnt>
But the rail is needed to power the NVCM where the HFOSC calibration is read from.
<emeb>
Ah, interesting detail.
<emeb>
I was wondering how they calibrated that.
<tnt>
maybe trim got broken and enabled by default ?
<emeb>
Well, reflowed the VPP pad - it's got a nice meniscus on it. Diode drop didn't change and I'm still seeing 19.3MHz with TRIM_EN = 1b0.
<emeb>
I guess this part is either damaged of "one of a kind"
<emeb>
or
<emeb>
The bitstream is being loaded via SPI + GPIO toggling from an RPi. Is it possible that bad timing on the SPI interface could be messing up the NVCM read?
<emeb>
ie - at what point in the configuration process does the trim value get loaded?
<daveshah>
I don't actually know
<daveshah>
it seems possible though, you could try a bigger gap between creset and starting to send data; and make sure you send the correct number of clocks after the data
<emeb>
Yeah - I'm using a hacked-up version of Jan Marjanovic's ice_config.sh script and it doesn't appear to be sending trailing zeros. I suspect that's the first place to look.
sgstair_ is now known as sgstair
emeb_mac has joined ##openfpga
jemk has quit [Remote host closed the connection]
jemk has joined ##openfpga
<emeb>
Gah - this script does so many things wrong. Probably due to it running in bash and the overhead for doing the bitbanging is high.
<daveshah>
Ouch, ice40 programming directly in bash?
<daveshah>
Using sysfs or something?
<zyp>
perfect tool for the job!
<emeb>
It's using the sysfs GPIO interface to do the RST, SS bitbanging and dd to send the bitstream to spidev
<emeb>
and it only checks DONE after sending the trailing zeros
<emeb>
frankly amazing that it works at all.
OmniMancer has joined ##openfpga
<daveshah>
Oh, at least it isn't using sysfs for the actual bitstream
OmniMancer has quit [Client Quit]
<emeb>
no, the SPI port works fine for that, although I do see pauses in the clocking that may be while it reads blocks from SD
OmniMancer has joined ##openfpga
<emeb>
the config guide says that the clock shouldn't pause, but that doesn't seem to hurt.
<emeb>
but it's definitely not managing the SS per the spec
<daveshah>
In practice I think it's fine unless you go really slow and then there is a timeout (maybe 1s or something)
<emeb>
yeah, these are short.
<daveshah>
The FTDI based programmers are unlikely to have a continuous clock either but all work fine
<emeb>
Interestingly, reading the Programming and Configuration document - the text description of slave programming and the accompanying figure do not agree at all.
<emeb>
Figure 13.2 shows setting SS high and sending 8 dummy clocks, then setting SS low again prior to the bitstream, then raising SS and sending dummy clocks until DONE goes high. The text makes no mention of this - just says send the bitstream and send 49 dummy clocks and DONE will go high on its own.