<conmega>
Got a tinyfpga BX awhile ago and decided to port a project I was working on with an ALTERA board in VHDL over to Verilog with this board. Its to drive an EL display and so I have a video memory. Now I need 9600 bytes of storage to fit the video ram, which the BX should have 16KB so I should be within the relm of fitting on the board. But the video data is in 4-bit chunks and I'd like to
<conmega>
be-able to write to the display in bytes. So to start I made an 8-bit wide reg with 9600 positions then just added a statement to address either the top nibble or bottom nibble based off the LSB of the address for the video generation logic. This gets stuck in PNR for hours... Tried changing it to a 4 bit register with 19200 position and just addressing it straight, works fine. Any ideas?
<tnt>
conmega: idea about what ?
<tnt>
conmega: RAM inference is often very dumb, so unless your verilog match a very precise pattern it's designed to match, it won't infer a ram and it will use flip-flops.
<conmega>
Well so ok, I suppose I should be clearer, it just fails to route if I try and access only 4-bits of an 8-bit wide memory, if I access all 8-bits of an 8-bit reg or 4-bits of a 4-bit reg it can route? Also I was wondering that but I can't find any other way people are defining block ram other than just a massive reg statement? I checked the datasheet and there are a few ways to address the
<conmega>
block ram, down to 4Kb chunks in either 16,8,4,2-bit wide configurations. So it seems to have difficulty routing my if statement basically.
<conmega>
So I suppose your saying unless the verilog is written in a specific way to address the reg then the place and router won't know to use BRAM? I suppose I could write it to just be an 8-bit block ram accessable via all 8-bits then have another module that splits the data up. Maybe seperating it like that will make it more happy?
<tnt>
What's wrong with the "THIS WORKS" version in your pastebin ?
Miyu has joined ##openfpga
<conmega>
Its not the format of data I want. I excluded some other code for a second port which I hadn't gotten to yet. But I'm basically trying to get a ram that allows writting data 8-bits at a time and reading 4-bits at a time. I figured the easiest way to do this would just be to just either grab the top nibble or bottom nibble based on the LSB of the address in. Then I was going to add write
<conmega>
logic to write 8-bits into the 8-bit wide ram.
<conmega>
I simply made the part that works as a simple test to ensure it will actually allow me to use that much BRAM and actually route and place on the chip.
<tnt>
Then yeah, describe the ram as 8 bits, and on the side, in another process, take the 8 bits you read from the RAM and add a mux to select which nibble to use.
<conmega>
Hah, awesome works beautifully! Thanks a bunch. I suppose I could see how you defined it would better define the logic I meant to define...
<tnt>
Yeah, that's why it's called 'Hardware Description Language', you should always try to describe the hardware you want built rather than the behavior you want.
<conmega>
Yea... Bit of a learning curve heh... I've dabbled in a little bit of everything from ASM to Python but still quite new to HDL.
<conmega>
An older EL display with a 4-bit data, Video clock, Hsync, Vsync interface. Seemed like a reasonable project to get started with some HDL.
<tnt>
That's a facny EL display :)
<tnt>
the 4 bits are just consecutive pixels right ? not intensity ?
<conmega>
Yea, this EL has no concept of intensity, but can be driven at 120hz for refresh so you could theoretically get intensity by toggling the bit 4 times within a second to get 30 FPS with maybe a few levels of intensity but it'll probably not look quite right and require a lot more ram.
<conmega>
But yea, really loving HDL once I figured out how to write test benches haha. Before that its like ripping your hair our poking at pins with the logic analyzer/scope heh...
Thorn has quit [Read error: Connection reset by peer]
Thorn has joined ##openfpga
emeb_mac has quit [Ping timeout: 248 seconds]
<xobs>
Update on valentyusb: I think I found the source of metastability. Possibly in the io -> usb_48 crossing, and almost certainly in the usb_12 -> usb_48 crossing. I'm synthesizing a bunch of tests now to make sure it'll work with these fixes.
<tnt>
xobs: did you ever switch to using IO registers ?
<xobs>
tnt: I'm not quite sure what you mean, but I'm using a two-register chain on the inputs now.
<tnt>
IO blocks have input / output registers built-in.
<whitequark>
but in a Verilog, you describe hardware "behaviorally"..
<whitequark>
... or are supposed to, anyway, I agree that it doesn't work very well :)
<tnt>
whitequark: yup, it sucks :) You basically play a game of writing the behavioral patterns that you know will match the pattern recognition of the synthesizer to generate the hardware you want.
<whitequark>
... or you use nMigen, which outputs a structural description instead
<tnt>
well that's the input that matters, not the output.
<whitequark>
oh?
<tnt>
I might just be mis-expressing what I mean, but I'm busy atm, gotta finish something.
<whitequark>
yeah sure
<daveshah>
The biggest problem with BRAM inference is not that you need to match an exact pattern, but that there is no standard for what that pattern is, imo
<daveshah>
Anything remotely non-standard is unlikely to work in anything other than the synthesis tool it was written for
<whitequark>
yeah
<whitequark>
if the pattern is standardized then the behavioral and structural verilog that only use standard patterns are semantically close to equivalent
Asu has joined ##openfpga
<daveshah>
This is quite an FPGA-specific problem (not unimportant though), I don't think the ASIC world really has BRAM inference
<daveshah>
Small RAMs are bit-blasted anyway, large RAMs are built with a memory compiler and dropped in
<mwk>
bit-blasted?
<daveshah>
Converted to logic and DFFs
<mwk>
ah
bibor has quit [Ping timeout: 268 seconds]
_whitelogger has joined ##openfpga
<xobs>
"ICESTORM_LC: 5278/ 5280 99%" <--- How did this manage to route /and/ meet timing?
<whitequark>
lots of registers?
<xobs>
Must be.
<daveshah>
iCE40 also have more routing resources per LC than many other FPGAs
<xobs>
Yeah. It's really is impressive.
<whitequark>
they're so stringy on SEM
<tnt>
Well your target is 12 MHz ...
<xobs>
tnt: the domain that usually has trouble meeting timing is the 48 MHz one.
<daveshah>
Routing resource density is mostly a function of how much confidence the vendor has in their PnR flow
<whitequark>
ha
lutsabound has joined ##openfpga
<daveshah>
Hence the Ultrascale having ridiculously sparse routing compared to iCE40
<tnt>
lol
<daveshah>
For a startup like SiliconBlue a bit more VC cash on a larger die is much easier than finding coders for better PnR algorithms
pie_ has quit [Ping timeout: 276 seconds]
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
<ZirconiumX>
daveshah: tangentially related, why was nextpnr created if arachne-pnr already existed?
<daveshah>
ZirconiumX: To add support for multiple architectures (eg ECP5), timing driven pnr, and a framework for developing more advanced pnr algorithms
<ZirconiumX>
So arachne-pnr wasn't flexible enough?
<daveshah>
No it was really hard coded as a first pnr for the iCE40
<ZirconiumX>
Okay, that's fair
<daveshah>
There was nowhere near enough of arachne-pnr that would be kept to be worth using it as a base
wpwrak has quit [Ping timeout: 245 seconds]
wpwrak has joined ##openfpga
Miyu has quit [Read error: Connection reset by peer]
Miyu has joined ##openfpga
Asu has quit [Ping timeout: 245 seconds]
Asu` has joined ##openfpga
cr1901 has quit [Quit: Leaving.]
cr1901 has joined ##openfpga
Jybz has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
cr1901 has quit [Quit: Leaving.]
cr1901 has joined ##openfpga
Asu` has quit [Remote host closed the connection]
Asu has joined ##openfpga
anuejn has quit [Quit: No Ping reply in 180 seconds.]
<azonenberg>
daveshah: yeah i have yet to see an asic tool that can infer srams from rtl
<azonenberg>
What i do in FPGA is have a "MemoryMacro" module for any nontrivial size ram
<azonenberg>
that has parameters to specify target as block, ultraram, lutram, etc
<azonenberg>
width, depth, number of pipeline stages
<azonenberg>
inside is a behavioral description of a ram that is designed to match the synthesis tool's patterns
<azonenberg>
then you can tweak that one module as needed if you move to a new fpga
Miyu has quit [Read error: Connection reset by peer]
Miyu has joined ##openfpga
<whitequark>
daveshah: do you remember if there's some FPGA family that has native latches?
<whitequark>
i remember there was some weird family of FPGAs (chinese maybe?) that was LUT-only and used latches as storage
<whitequark>
but i can't find it
<whitequark>
wait. is that just efinix trion
<tnt>
You mean modern ones? I know coolrunner had latches (although I guess they're cpld not really fpga)
<whitequark>
yeah modern
<whitequark>
hm, no, trion is a regular 4-lut arch
<whitequark>
4-lutff
<daveshah>
whitequark: all xilinx FPGAs have native latches too
<daveshah>
Technically speaking ECP5 does too (asynchronous data load mode on the FFs), but it's not exposed in the vendor tools or really in nextpnr either
<daveshah>
As the vendor tools don't use it I suspect it is broken in some subtle 3ay
<daveshah>
*way
<whitequark>
daveshah: so the story goes is emily wants some FPGA family to target with asynchronous logic
<whitequark>
and i remember there was *some* family with guaranteed glitchless LUTs
<whitequark>
but i can't find out what it is
<azonenberg>
i've never seen one that specifies that
<azonenberg>
maybe an older achronix part?
<azonenberg>
that was their big thing for a while
<whitequark>
rings a bell
<azonenberg>
they were trying to be the async fpga
<azonenberg>
But these days i think their chips are more general purpiose, they realized async doesnt really work with current eda tools
<whitequark>
well the point here is to develop better eda tools
<daveshah>
I suspect glitch free logic should be doable even with any FPGA arch LUTs if you are careful about input wire delays
<daveshah>
But some characterisation might be needed first
<whitequark>
yeah, ice40 would be interesting
<daveshah>
iCE40 probably makes most sense because of its low static power
<azonenberg>
I want to spend more time characterizing greenpak first because it's slow and cheap
<azonenberg>
then move up to something higher end like ice40
<whitequark>
sentence no one in the world has ever said before
<tnt>
Damn, I was surprised measuring HFOSC of UP5k on a random board, it was withing 3ppm of 48 MHz. Then i tried on another board and it's like 2000ppm off. Random sampling ...
<daveshah>
Still, I've never found one near the 5% or whatever the datasheet says
<daveshah>
But I guess that has to cover aging and temperature
Miyu has quit [Ping timeout: 276 seconds]
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 264 seconds]
emeb_mac has joined ##openfpga
lutsabound has quit [Quit: Connection closed for inactivity]