<promach>
By the way, ZipCPU, did you faced any issue regarding tcl85 during yosys installation ?
m_w has quit [Quit: Leaving]
<ZipCPU>
No. I had no issues.
<ZipCPU>
Or at least none that I can remember.
<promach>
Should I create a github issue on this because I am not sure if this is really problem with yosys makefile because I only have problem in Ubuntu but not in arch linux ?
<ZipCPU>
I had no problems in Ubuntu 16 or 18.
<ZipCPU>
I'd be hesitant to create a github issue yet.
<promach>
ok, let me check this again over the weekend. Probably I made some mistake
<ZipCPU>
One other thing ... .I have tcl8.6 installed, not tcl85
<promach>
me too
<ZipCPU>
Do you have libtcl8.6 installed?
<promach>
yes
<promach>
libtcl8.6 is already installed at the requested version (8.6.8+dfsg-3)
<ZipCPU>
How about tcl-dev and tcl8.6-dev ?
<promach>
already installed
<promach>
tcl-dev is already installed at the requested version (8.6.0+9)
<promach>
tcl8.6-dev is already installed at the requested version (8.6.8+dfsg-3)
<ZipCPU>
So .... what issue are you struggling with?
<daveshah>
ric96: why do you thing mode 3 is a problem?
<daveshah>
*think
<ric96>
daveshah: even if i go to mode 3, still limits me to only 5 blocks
<ric96>
instead of full 16 blocks
<daveshah>
ric96: first of all mode 3 is correct behaviour, not a problem, if you think about the resultant output it will require less decoding logic than mode 0. limiting to 5 blocks seems to be a separate problem
<daveshah>
what happens when you go above 5 blocks. what error do you get? is it in Yosys or arachne-pnr?
<ric96>
i can use mode 3, not an issue. issue is limiting to 5 block, sorry wasn't clear
<daveshah>
ric96: yes. what is the problem you see when you exceed 5 blocks. what is producing the error? yosys or arachne-pnr?
<ric96>
daveshah: don't know new to this... posted the output above if you can figure out
<daveshah>
ric96: are you resizing your address input to the module? it looks like the address input to the module is only 8 bits. This means the top parts of your memory are never accessed, so Yosys will optimise them away
<daveshah>
ric96: no you are not, have a look at line 4
<daveshah>
this means that the address to the memory, however wide the internal address signal is, can only be between 0 and 256
<daveshah>
*0 and 255
<daveshah>
so yosys will optimise away any unused memory above that
<ric96>
daveshah: oh.... ok let me try again after resizing
<mattvenn>
yosys optimising things away has caught me out many times too! But if you capture the output of the synthesis, you can grep for remove and see all the stuff not being used
<mattvenn>
also, yosys show gives you a visualisation of what is actually inferred
<daveshah>
also, make sure you are actually checking the Yosys output netlist or the arachne-pnr resource count
<daveshah>
the Yosys command line output you posted before was more about elaborating module configurations and may not be repeated for every BRAM in the design, I'm not sure
<daveshah>
ric96: clearly by the number of IO something is using that BRAM module. Where is the BRAM module being used? How much memory is actually being used (I'll guess less than 20kBit...)
<ric96>
daveshah: just writing zero in the initial block
<daveshah>
ric96: what top level module contains ram1?
<ric96>
And writing one bit in the top module... Yes it does.
<daveshah>
ric96: if you only write one bit, Yosys will optimise away the other bits
<ric96>
daveshah: yikes... Ok I'll write to all blocks and see if that works.. thanks
<daveshah>
ric96: Yosys can be pretty smart, at least some of the time :-P
<mattvenn>
I still have questions about this
emeb has joined #yosys
<mattvenn>
most recently I was working on an FFT project, and I hadn't used the output of the FFT for anything
<mattvenn>
so I could simulate it and show it worked
<mattvenn>
but couldn't get an understanding of LUT usage as I changed the number of FFT bins
<mattvenn>
because I couldn't convince yosys I was using it!
<mattvenn>
I'd like to know what rules yosys uses to know if something should be optimised out
seldridge has joined #yosys
promach_ has joined #yosys
<awygle>
I don't know what the specific rules are, but in general, anything attached to a top-level port will be kept
<ric96>
daveshah: BRAMs 16 / 16 FINALLY!!! Thanks for the help
<ric96>
daveshah: one more thing, better way to zero all ram bits without the for loop, that takes too long to process in yosys
<daveshah>
ric96: I think the only other option is to use $readmemh and a file full of zeros
<ric96>
ok, i'll give that a go, anything is better than a for loop that takes forever
xa0 has quit [Ping timeout: 260 seconds]
xa0 has joined #yosys
jaafar has joined #yosys
maikmerten has joined #yosys
m_t has quit [Quit: Leaving]
<maikmerten>
I'm trying to design a board to attach 512Kx8 SRAM to the Lattice HX8K breakout board - it doesn't come with any RAM. Now, sadly none of the 40-pin connectors (one for each I/O-Bank fo thh FPGA) have enough I/O-pins to drive the 30 signals I need (19 address, 8 data, 3 control), so I need to spread over two headers
<maikmerten>
which means two I/O-banks being involved
<maikmerten>
I wonder if this introduces some timing skew, e.g., with one bank being offset slightly
<maikmerten>
which means I wonder if I should take some care to make sure that, e.g., all address, data and control lines are assigned to one bank only - and not smeared across
<daveshah>
maikmerten: I doubt it will be significant compared to other sources of skew tbh
<daveshah>
what speed are you planning on running at?
<maikmerten>
well, between 20 and 40 MHz, whatever ends up being stable
<maikmerten>
(it's 10ns SRAM, but I don't trust the signal routing on the breakout, the pin headers, and whatever board design I come up with)
<awygle>
yeah i don't see why the bank used would be significant in this case, except maybe for your own sanity
<maikmerten>
okay, thanks
<maikmerten>
I guess I'll still try to keep the same "class" of signal on one single bank
<maikmerten>
but perhaps the routing will make me reconsider ;-)
<awygle>
yeah don't put a spoon in your eye over it
<maikmerten>
for reference: This is a board I designed for one of those very cheap Cyclone-II boards: https://pasteboard.co/Hu8fHAY.png
<awygle>
yeah i've run 100 MHz over 100-mil headers before
<awygle>
i would have put some series termination on the board though. unless the i/o are slew rate adjustable
<maikmerten>
they are not ;-)
<maikmerten>
not sure if there's a "one size fits not all, but most" approach to series-termination though. I guess for a proper value one would have to make some educated guesses on the impedance and whatnot
<maikmerten>
"In most designs, a value of R = 25 Ω to 30 Ω is recommended"
<maikmerten>
aha
<awygle>
for 50 Ohm lines (which is what i almost always use for impedance control) 22 or 27 ohms is a decent guess for most drivers
<awygle>
lol oh hey look at that
<awygle>
yeah that matches my intuition/experience
<maikmerten>
:-)
<awygle>
i wish IC manufacturers spec'd output impedance
<maikmerten>
surprisingly, apparently, in many cases intuition seems to work just fine as long as frequencies remain "low"
<awygle>
intuition works OK at higher frequencies too, it's just different intuition :p
<awygle>
the most valuable intuition to have is knowing when you need to run the simulation tbh
mjoldfield has quit [Read error: Connection reset by peer]
mjoldfield has joined #yosys
<maikmerten>
I'm a computer scientist, not an electronic engineer, and when it comes to PCB stuff, I usually end up being lucky, I guess. I may be doing some ill-conceived hocus-pocus in some cases though. For instance, keeping as much GND-fill on the board as possible (no islands allowed), which might be counter-productive in some cases, I guess.
<mattvenn>
19 address for 512kx8?
<maikmerten>
(and yeah, simulation rocks. As long as one has enough data - or intuition - to get the parameters right)
<maikmerten>
mattvenn, yup
<mattvenn>
oh yeah
<maikmerten>
2^19 = 524288
<mattvenn>
sounds like loads of pins for only 512k!
<ric96>
daveshah: anyway to force yosys to use different read/write mode... Its seems to be only happy with mode 3
<maikmerten>
no col/row multiplexing there ;)
<daveshah>
ric96: it's picking mode 3 for a good reason
<ric96>
Defaults to that mode no matter what
<daveshah>
if you want to use another mode, instantiate the primitive yourself. But I don't know why you need mode 0, this sounds like an XY problem tbh
<mattvenn>
I've just been testing Kevin Hubbard's hyperram breakout
<awygle>
maikmerten: ground fills are fine as long as they're well stitched and you pull them back from anything you're analyzing with microstrip formulae
<maikmerten>
(as for other hocus-pocus (i.e. stuff I do that is not backed up by proper data): Avoiding routing signals through vias if possible, although this doesn't appear to be a problem per-se - BGA escape-routing usually relies heavily on vias)
<maikmerten>
ah, thanks :)
<awygle>
vias add inductance but aren't a big problem in themselves. and sometimes they're unavoidable, and sometimes going too far out of the way to avoid them adds *more* inductance. what you really want to look at is reference planes, but that's a more complicated topic.
* awygle
is making a list of future blogs...
proteus-guy has joined #yosys
dys has joined #yosys
tinyfpga has quit [Ping timeout: 256 seconds]
tinyfpga has joined #yosys
pie___ has quit [Ping timeout: 244 seconds]
emeb has quit [Ping timeout: 240 seconds]
mjoldfield has quit [Read error: Connection reset by peer]
mjoldfie_ has joined #yosys
emeb has joined #yosys
<maikmerten>
one of the weird features of the HX8K breakout board: On the four headers, the VCCIO{0-3} for the respective I/O-bank is accessible, but only on one the VCC33 line is available. The VCCIO-lines are derived from VCC33 via a filter-arrangement (an inductance, an 1-Ohm resistor, some capacitors) and it feels "wrong" to derive power for the SRAM from there... that one can source up to 180 mA when in full swing
<daveshah>
personally I'd replace at least the 1-ohm resistor with a 0-ohm resistor, if you are comfortable replacing an SMD resistor
<daveshah>
i'm not convinced the 1-ohm resistor will be doing much anyway
<maikmerten>
yeah, but OTOH I guess someone put some thought into that...
<maikmerten>
also, given that I need to spread over two headers, I can just take VCC33 from the one that I'll occupy anyways
<maikmerten>
it's just funny that on all headers, in the schematics, there is a very clear note: "MAKE PWR TRACES CAPABLE OF 1A"
<daveshah>
tbh Lattice, thought and development boards don't always go together
<daveshah>
there've been critical errors with PLL supplies before now
<maikmerten>
even on those that don't expose VCC33
<maikmerten>
(and the linear regulator for VCC33 can deliver like 650 mA max)
<maikmerten>
(okay, continuous current - and that note may be for spikes or whatever)
<maikmerten>
yeah, I've heard of one particularly inexpensive board that just forgot decoupling on the PLL supply completely
<maikmerten>
despite there being a hardware design checklist that isn't even hard to read
<maikmerten>
(and not being very long)
<daveshah>
yeap
<daveshah>
and then people copy them because they think they are a golden reference (which they should be) ...
<maikmerten>
yay, VPP2V5 is derived from the 3.3 Volts supply... relying on a diode to drop 0.7 Volts
<maikmerten>
(I think that 2.5 Volts is only used for the NVCM stuff, which I'll sure never use)
<maikmerten>
I would think the voltage drop of the diode would be current-dependant, though, and the current here should be very low...
<daveshah>
if you look in detail, many of their boards use a schottky diode that drops nowhere near 0.7v...
<maikmerten>
I'll just take this as a hint that their chips are somewhat robust ;-)
<daveshah>
yeap
<maikmerten>
ooooh, I think that "filter arrangement" (inductor, resistor, capacitors) for the VCCIO-lines might be a valiant effort to ensure a proper power-on sequence
<daveshah>
maybe, sounds a bit dodgy
<maikmerten>
because, /me being naive, I wouldn't expect there to be much noise to filter out from a linear voltage regulator
<daveshah>
I've never seen an iCE40 fail due to bad power up sequencing TBH
<daveshah>
I suspect it could be to stop noise getting in from external devices
<maikmerten>
yeah, hmmm...
<awygle>
the 1 ohm resistor is probably for power measurements.
<awygle>
and the filtering could be an attempt to keep the VCCIOs from cross-contaminating
<daveshah>
yes, power measurement makes sense
<awygle>
it does sound a bit weird though tbh
<awygle>
any standard 1R resistor should handle 180 mA from a power dissipation perspective though. and dropping 0.18 V should be fine.
jwhitmore has quit [Ping timeout: 240 seconds]
jwhitmore has joined #yosys
pie___ has joined #yosys
<mjoldfie_>
It would be easy enough to solder a bit of wire across the resistor or pads even if you don't like SMD soldering.
promach_ has quit [Ping timeout: 264 seconds]
pie___ has quit [Ping timeout: 240 seconds]
m_w has joined #yosys
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #yosys
jwhitmore has quit [Ping timeout: 260 seconds]
maikmerten has quit [Remote host closed the connection]
<mithro>
So, when I run "proc" in yosys I'm getting the following
<mithro>
Warning: Replacing memory \storage with list of registers. See ../../../../vpr/mem/vpr_sp_ram.sim.v:18
<mithro>
And yosys becomes very slow....
<daveshah>
mithro: most likely you're doing something that Yosys does not support generating a memory for
<daveshah>
This means is explodes to lots of registers
<daveshah>
mithro: couldn't find a good example of this to hand but this above should be vaguely correct
<daveshah>
For a single port ram with clocked write and unclocked read, if that's what you want
<awygle>
it looks like in order to match the picture he sent that addr and wen and wedata all need to be registered
<awygle>
(inexplicably)
<daveshah>
Updated example accordingly
<daveshah>
I don't feel like the what the picture describes is really correct, it would be a race condition between wen and wdata/addr unless you were very careful
<daveshah>
I've never seen registered wen into an async memory as opposed to just a clocked write port with a wen input
<awygle>
out would definitely be very glitchy
<awygle>
i have no idea why you'd implement something that looked like that
<daveshah>
It seems to be a contrived example for VPR rather than anything you would practically want
<awygle>
yup
<daveshah>
They claim that the output port is combinational. But a combinational output port without any combinational inputs seems very odd
<awygle>
yup
<mithro>
You make async ram synchronous by adding registers?
<daveshah>
Yes, although the reality is a bit more complicated than just adding a register in front
<mithro>
So if the "cloud" is a combinational block
<daveshah>
Not least because of the we/data race we just discussed
<daveshah>
mithro: I think the example structure is simply from a timing point of view, rather than a real world implementation
<daveshah>
Or a sensible HDL implementation
<mithro>
Yes, that is correct - it is talking from a timing point of view
<mithro>
If you replace cloud with just some random combinational logic rather than memory (like a DSP hard logic) does it make more sense?
<daveshah>
mithro: yes, a DSP is a much better example
<daveshah>
The memory write port is by nature not purely combinational, which was the problem
jwhitmore has quit [Ping timeout: 240 seconds]
<daveshah>
In a typical DSP structure you would have configurable registers at the input and output, plus configurable pipeline registers in the middle
<daveshah>
If only the input registers were enabled it would match that structure
<mithro>
How does a write port actually work? Is it more like a tristate? When WEN is low it doesn't drive anything into the cells?
<daveshah>
mithro: No, it would be closer to the enable input of a latch I suppose
<daveshah>
Of course it would be decoded so only a single location was selected
<mithro>
Really, I think what that diagram is trying to show is delay T after the clock edge the output is stable?
<daveshah>
mithro: yes
<daveshah>
Normally I've seen that implemented just using a high clock to Q time rather than the combined sequential and combinational approach
<mithro>
So the clock signal for the storage latches must be, wen & clk ? IE wen is working like a clock enable for a write clock?
<daveshah>
mithro: yeah, in a clocked write port it would look a bit like that