<tnt>
AFAICT it might be detecting edges that violate timing.
<daveshah>
That makes sense, given the EDETERR port
<tnt>
daveshah: wrt to 800ps coarse delay: was that with the coarse mode set to DYNAMIC ?
<daveshah>
I think that was in static mode
<tnt>
Do all the mc1_xxx stuff map to config bits ?
<daveshah>
Yes, mc1 is the Lattice prefix for a config bit, it was used in ECP5 too
<daveshah>
I am not sure what it stands for, memory cell 1 bit perhaps
<tnt>
daveshah: btw, I have spare PCBs for my NX-SG72 test boards and I also have spare PCBs from greg davill's breakout as well if you're interested I can ship both to you.
<daveshah>
Thanks for the offer, I've just ordered a very simple breakout board that is more within my current capabilities...
<tnt>
ok sure. I would have have offered to ship you a populated board if I had spare chips :)
<daveshah>
Yeah, I don't want to risk the one chip I have too
<daveshah>
Official EVN boards should be available end of Feb according Mouser so not too bad though
<tnt>
Yeah, I have one ordered already.
<tnt>
Although I'm wondering ... supposedly Lattice gave 5 of them away to open source devs ... where did those go ...
<daveshah>
Nowhere near me!
<daveshah>
Where did you hear that from, btw?
<tnt>
At 36c3 but can't remember from who though :/
<daveshah>
I would guess that is more for the kind of devs they like
<daveshah>
writing AI IP cores or something
<daveshah>
Hmm, looks like Radiant totally ignores the DEL_VALUE parameter
<daveshah>
which makes the DELAYB seemingly useless
<daveshah>
unless I'm missing something in these bitstreams
<tnt>
Or radiant is buggy :)
<daveshah>
Yeah that is most likely here
<tnt>
does it take it for DELAYA ?
<daveshah>
Seems to ignore it for DELAYA too
<daveshah>
as far as I can see it accepts it without warning; but changing it doesn't actually affect the bitstream
emeb has left ##openfpga [##openfpga]
<tnt>
daveshah: what do you set it to ?
<daveshah>
I was trying various random values; 1, 2, 3, 80
<tnt>
as a string ? ie ("80") and not (80)
<daveshah>
The setting seems to make it through to the attributes in physical view, so I think it must be a bug in bitstream generation
<daveshah>
As a number
<tnt>
The "wizard" uses strings for those.
<tnt>
no idea if that has any influence or not though ...
<keesj>
Ok I see thanks. I was looking at the OrangeCrab and the sheet for ddr3 is called hyperam but this is probably just for historical resons. I also found some "hyperam" here https://www.ram-tec.nl/product/hyperam-2gb-pc2-6400u/ but that also does not match the orange crab
<tnt>
daveshah: btw, I definitely reproduced your results from last night ... changing DEL_VALUE seems to have no effect. And the coarse delay only seems to have 2 values (0ns and 0.8 have the same bitstream result afaict ...)
<tnt>
Orange Crab is definitely DDR3L, I think he thought about hyperram at the beginning since another of his board uses that but went with DDR in the end.
<daveshah>
tnt: thanks!
<daveshah>
On the subject of DDR3/HyperRAM, I'd love to see Etron RPC become generally available
<azonenberg>
That being said, i did refer to a 1024-bit quantity as a word not too long ago
<azonenberg>
since it was a single row of a 1024-bit wide sram
<sorear>
also I mixed up my channels and thought you were criticizing something I said somewhere else
<daveshah>
finnb: I met one of that team last year, they seemed like quite an interesting company (even if I don't personally agree with Go on FPGAs)
<daveshah>
I'm a bit concerned that their website is offline and the GH hasn't updated, maybe they've gone bankrupt
<finnb>
daveshah, why do you disagree with golang on fpgas?
<finnb>
I think it's kind of neat. I've written a lot of verilog and vhdl to know how much of a PITA they can be when trying to anything dsp heavy. I could see a layer of abstraction in a language that inherently has concurrency baked into it to be of some help.
<daveshah>
Oh definitely, I support high level design overall, I'm just not much of a Go fan
mumptai_ has quit [Remote host closed the connection]
<finnb>
What would you choose?
<daveshah>
I don't know
<daveshah>
I think something that is more DSL-like (I might do some HLS-y stuff in nMigen at some point)
<finnb>
The problem I'd have with that is say I have 100 developers who are all happy writing Python, Java, C++; I want to pick a language they'd be comfortable spinning up on. Golang for me seems like a natural choice
<finnb>
It has a smaller subset of syntax to implement than most languages. For example I think Rust would be too hard to make a HLS out of, even after its recent async update
<daveshah>
I guess I'm wary of anything that aims to "compile" something to FPGA rather than something more like an embedded DSL type thing
<finnb>
So a DSL would be more of a hardware description kind of thing?
<finnb>
I'm not too familiar with the term
<daveshah>
Yeah, I'd like to see something like that but with traditional HLS features like pipeline generation
<finnb>
I wonder if people felt the same when trying to leave Assembly for C :P
<finnb>
I get what you mean about pipeline generation
<finnb>
I wonder if you could somehow get that into golang
<daveshah>
I've personally built a very-small-C-subset-to-pipeline thingy a few years ago
<daveshah>
But you easily end up with pitfalls
<daveshah>
The problem with assembly for C metaphors is that programming languages don't really fit FPGAs well
<finnb>
You're right there too
<daveshah>
Hence why I am starting to prefer using them to describe hardware (even if at a high level) rather than turning them directly to hardware
<finnb>
I'm very happy to write VHDL + Verilog but converting 1000s of engineers to do the same is just a no-starter. Are there any other HLS tools you'd recommend looking at?
<daveshah>
Not really but it's not a space that I've investigated much
<daveshah>
I've heard people liking Clash but I haven't used it myself
<sorear>
C is described in terms of an abstract machine which, historically, mapped fairly directly to the abstract machine seen by assembly programmers
<sorear>
I guess HLS is no more of a leaky abstraction than VHDL&Verilog already is (what is a synthesizable construct? nobody knows, except by reference to what the tools do and an IEEE document that was obsoleted without replacement decades ago)
<sorear>
imagine a world where assemblers don't exist, every CPU vendor ships an Ada compiler, 99% of programmers don't know Ada but have to transpile their favorite language
<sorear>
verilog is used as a compilation target but it's terrible at it because it's a lifetime ago's idea of a high level language, in ways that are sideways from useful
<finnb>
Why do you think it's terrible?
<finnb>
At the end of the day with Verilog, when I write it, I can generally have a very good guess about what it's going to do on the FPGA unless I've made some silly error
<sorear>
I'll let someone else who's better at it handle that one
<sensille>
was it really the idea of a high level language?
<sensille>
and not just a description language?
<whitequark>
finnb: because it's not actually standardized in any meaningful way
<whitequark>
for example, try to answer this question. what is the semantics of always_ff in SystemVerilog?
<finnb>
I've never really used SystemVerilog :)
<finnb>
More VHDL than Verilog
<finnb>
I'm guessing that means always flip flop?
rombik_su has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 258 seconds]
Lord_Nightmare has joined ##openfpga
keesj has joined ##openfpga
<daveshah>
Not quite a complete routing graph yet, and only quickly tested, but the prjoxide deduplicated bba generator now takes 0.679s
<daveshah>
I guess that will make a lot of people happy
rombik_su has quit [Quit: Leaving]
rohitksingh has joined ##openfpga
<tnt>
daveshah: nice :)
<tnt>
daveshah: btw, anything we can do to help prjoxide ?
<daveshah>
I might need you to test some bitstreams in a week or two, if I don't have hw sorted by then
flea86 has joined ##openfpga
<tnt>
ok, sure np.
<daveshah>
There will probably be more to help with once more of the frameworks (like the base nextpnr and Yosys arch) are in placr
<daveshah>
*place
<tnt>
Yeah I figured that in the early stage it's just hard to split or delegate.
<daveshah>
Afraid so - poking around Radiant and NX features in general is probably as useful as anything else
<miek>
ship date for new NX stock keeps moving forward :(
<tnt>
miek: yeah, it's fixed to today() + 7
<daveshah>
I'm not sure if the 1 week lead time is actually a real estimate even, or just a placeholder someone put in
<tnt>
Don't think so. I ordered one (back ordered) around christmas and it's not here :)
<miek>
doh, has it just been doing that since it went out of stock?
<tnt>
miek: yes
<daveshah>
Yup
<tnt>
interesting that the cs289 only has 12 less IOs than the ca400.
<daveshah>
Yeah, although I guess a lot more work to use all the IO
<tnt>
yeah, for the cs289 you need 6 layers and not the cheap processes ...
* swetland
sighs at all the python goop in prjxray (not a fan of a ton of crap that needs to be dumped into the environment for things to work)
<daveshah>
Hmm, I asked on DigiKey web chat about the LIFCL lead time. They said that 1 week is an actual estimate for parts to be shipped from Lattice to them
<daveshah>
There is still a limit of 1/order, but multiple orders are allowed.
<omnitechnomancer>
daveshah: oooh, good to hear bba generation is working, what strategy did you go with for generating the deduplicated db?
flow has joined ##openfpga
<daveshah>
For each tile type; I consider the set of possible "neighbourhoods" of tile types (based on how wires in that tile are connected). Then for each of those possible neighbourhood types I store a mapping from wire index in current tile type to wire indices in neighbours
<daveshah>
The iterators from getPipsUphill, getPipsDownhill; etc all look at the entire neighbourhood of a wire
<omnitechnomancer>
ah
<omnitechnomancer>
is that to handle things like the io tiles attaching to multiple routing tiles?
<daveshah>
Yeah
<daveshah>
and the fact that each routing tile attaches to multiple routing tiles too
<omnitechnomancer>
for the intertile interconnect stuff?
<omnitechnomancer>
So the neighbourhoods deals with the edge of the tilegrid getting weird?
<daveshah>
Yes, and things like wire indices being different in different tile types
<omnitechnomancer>
Ah
<daveshah>
generally, it deals with all these irregularities
<omnitechnomancer>
I wonder how far one could get by adding imaginary "global" wires that exist in every tile to deal with that aspect
<daveshah>
It would be another option that would probably work too
rohitksingh has quit [Ping timeout: 260 seconds]
<omnitechnomancer>
What are Branch(L|R) neighbours?
<daveshah>
They are part of the global clocking structure
<daveshah>
that isn't really handled yet, I need to special-case a few things for that
<omnitechnomancer>
ah okay
<omnitechnomancer>
I have not gotten to figuring out any global clock stuff yet
<omnitechnomancer>
What do the intertile routing wires count as?
emeb has joined ##openfpga
flea86 has quit [Ping timeout: 265 seconds]
<swetland>
almost got my own design working, xdc conversion was the most involved thing so far, but then
<swetland>
ERROR: Unable to place cell 'pll.mmcm_adv', no Bels remaining of type 'MMCME2_ADV_MMCME2_ADV'
<swetland>
does it just not know about MMCMs yet? I notice PLLE2_ADVs are listed in the resource summary but MMCME2_ADVs are not
<daveshah>
swetland: No, I don't even know if xray has the bits for them yet (it didn't when I added the PLL support to nextpnr)
<daveshah>
omnitechnomancer: the intertile routing wires in the db are generally things like E3:... which is a reference to a wire in a tile 3 to the east
<daveshah>
this then becomes a neighbourhood wire
<swetland>
no worries, I'm sure I can make PLLE2s work instead
<omnitechnomancer>
daveshah: ah so you just set them as offsets
<daveshah>
omnitechnomancer: yeah, they end up as rel_x and rel_y in RelWireInfoPOD
<omnitechnomancer>
I have a sinking feeling that some of the io tile stuff on eagle is non-uniform
s_frit has quit []
<omnitechnomancer>
daveshah: do you do something special about when those fall off the edge?
<daveshah>
There is a check and the neighbour wire is skipped
<omnitechnomancer>
ah good
<omnitechnomancer>
is that done in neighbourhood type construction or in the iterators afterward?
dh73 has joined ##openfpga
<daveshah>
Primarily in the iterators afterwards
<omnitechnomancer>
ah okay, that is roughtly what I had imagined doing with the "global" wires thing
<omnitechnomancer>
daveshah: are any of the io tiles in ecp5 disjoint in the bitstream?
<daveshah>
No, it looks like some of the CrossLink NX tiles are though - but in that case the vendor tool considers what would usually be one tile as two tiles
<daveshah>
so instead of one SYSIO_B7_0 tile you have one SYSIO_B7_0_C and one remaining slither in SYSIO_B7_0_REM
<omnitechnomancer>
I think the top and bottom io tiles in the anlogic part might be split over two locations for the "quads"
<daveshah>
as far as I can tell Radiant doesn't actually set the bits in SYSIO_B7_0_REM and as this only affects a couple of IO pins (and only some modes) in a the larger packages it is probably a bug
<omnitechnomancer>
hmmm, troubling
<omnitechnomancer>
I should put up a repo with the html output of the fuzzing
s_frit has joined ##openfpga
<daveshah>
Radiant 2.0 was definitely a rush job
<omnitechnomancer>
so I have iol_quad_t tiles, which seem to have two miscs_mic_io_t tiles associated, but the gclock ios also seem to have a miscs_mic_io_t tile associated
<omnitechnomancer>
so I am not sure how to deal with this
<sensille>
the ecp5 datasheet really avoids mentioning any value for 'weak pull-up/down' :-/
<omnitechnomancer>
what do you mean by value?
<omnitechnomancer>
pull-up/down that you are required to add or inside the chip?
<daveshah>
There is a pullup/down current in "DC Electrical Characteristics"
<daveshah>
there is no resistance because afaik it is more or less a current source/sink so a resistance has little meaning
<omnitechnomancer>
well inside the chip they are always transistors right?
<daveshah>
I guess you could create something more like a resistor, transistors certainly seem more common
<omnitechnomancer>
I mean resistors are hard to make in silicon and eat area right? so everything gets built out of transistors, even things you would use different methods in a discrete circuit
<daveshah>
basically, between 30µA and 150µA
<sensille>
great, thank you
<swetland>
oh joy. vivado is not accepting input focus any more.
<OK_b00m3r>
rip
<swetland>
wonderful. vivado hates my window manager. it gets along with whatever the crappy default ubuntu thing is
<noopwafel>
for some values of "gets along with", honestly
<swetland>
well, I can actually edit text fields again, so that's a plus
<swetland>
what(): Assertion failure: unsupported compensation type (/work/app/src/nextpnr-xilinx/xilinx/fasm.cc:1122)
<swetland>
terminate called after throwing an instance of 'nextpnr_xilinx::assertion_failure'
<swetland>
ah it doesn't like "ZHOLD"
<swetland>
hm. switching to "INTERNAL" or leaving at default gets the same exception
<daveshah>
I think "INTERNAL" is supported
<swetland>
yeah. hm. for some reason it thinks I'm using ZHOLD still
<daveshah>
btw, one other warning is that the timing data it uses is incorrect for xc7 at the moment, so Fmax figures it gives will be about 2x reality
<daveshah>
hmm
<swetland>
I dropped in a fprintf(stderr, "WAT %s\n", comp.c_str());
<swetland>
and am seeing WAT ZHOLD even with no ZHOLD appearing in the source any longer
<daveshah>
What is the Verilog you are using?
<swetland>
sv, but could easily use v for this file
<daveshah>
I meant the Verilog snippet for the PLL you are using?
<daveshah>
variant doesn't matter
<daveshah>
Just checked the PLL in one of the designs that works and it doesn't have a COMPENSATION parameter at all, relying on the default
<swetland>
I nuked the .json and .fasm files and now its failing to parse the input sv at all
<swetland>
okay it accepts INTERNAL if my input is parseable
<swetland>
prjxray.fasm_assembler.FasmLookupError: Segment DB CMT_TOP_L_UPPER_T, key CMT_TOP_L_UPPER_T.PLLE2.COMPENSATION.INTERNAL not found from line 'CMT_TOP_L_UPPER_T_X106Y44.PLLE2.COMPENSATION.INTERNAL'
<daveshah>
Looks like something has changed on the xray side
<tnt>
So ... how does one fix _hold_ errors ... like, I never had this in ISE or Vivado ... but here a simple design in radiant shows some and I have no clue how to fix them. Seems like something the _tool_ should do by picking another routing path to increase the data delay if it's too fast.
Zorix has quit [Ping timeout: 260 seconds]
<tnt>
It's _literarly_ the output of a FF going to the input of the FF of the next slice over ...
<swetland>
awesome. thanks. (no links to it from the family docs page)
<tnt>
Although "describe" is a bit generous, it's really just the pins, the info about what they do is really not always super obvious.
<tnt>
Some things could definitely use some illustrative timing diagrams.
* swetland
nods. just having a list of all the prims and their pins/props is a start at least
mumptai has joined ##openfpga
Zorix has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
<daveshah>
swetland: PLL FASM issue is now fixed, it was a change in how the Xray PLL settings look
<daveshah>
*fixed in nextpnr
* swetland
syncs and rebuilds
<tnt>
PLL in NX have a CRIPPLE params ... I thought it was some software limits lol ... turns out it's C_{ripple} as in a dynamic cap value.
<daveshah>
Yeah, I saw those too
<swetland>
I get a bit file now, no output from the board. re-building on vivado to see if INTERNAL upset things there
<daveshah>
It's nice they use real resistance capacitance and current values
<daveshah>
ECP5 just used numbers with some arbitrary mapping
<swetland>
vivado tells me this is an invalid pll config in internal mode.
* swetland
adjsuts
<swetland>
adjusts even
<swetland>
yay. design works in both nextpnr+xilinx and vivado
<swetland>
it works so much INSANELY faster in nextpnr
<daveshah>
Unfortunately Vivado still wins for runtime above about 5-10k LUTs
<daveshah>
primarily because of routing]
<daveshah>
router2 brings things a bit closer but still doesn't close the gap
* swetland
nods
<daveshah>
A timing model that isn't made up should help the router too (right now as a result pips don't have an accurate cost given how many tiles they cross)
solo1 has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
solo1 has quit [Read error: Connection reset by peer]
Jybz has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
rombik_su has joined ##openfpga
emeb_mac has joined ##openfpga
christiaanb has joined ##openfpga
<tnt>
wtf ... 125 MHz in, ask for 25 MHz out ... no pll lock :/
<daveshah>
Engineering samples....
rombik_su has quit [Quit: Leaving]
<GenTooMan>
Most time engineering samples work but TI let out things missing calibration so possibly the PLL isn't fully 'adjusted' in production yet.
<GenTooMan>
Then again it's an engineering sample for good reason :D
genii has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
Asu has quit [Remote host closed the connection]
<daveshah>
tnt: out of curiosity, if you haven't got the pll working yet can you try enabling the powerdown pin in the IP settings and tying it high (and low if that doesn't work or connect it to a switch)
<tnt>
daveshah: well it works for other frequencies than 25 MHz ... like 12.5M or 50M work fine ...
<daveshah>
Oh, must be something else then
<daveshah>
I was just suspicious how that pin really worked. But thanks for confirming
Asu has joined ##openfpga
<daveshah>
A hack would probably be to have CLKOP 50MHz and used for feedback only and take the 25MHz from CLKOS
<daveshah>
assuming it is something related to the feedback path or PLL core tuning rather than just a broken divider
flea86 has joined ##openfpga
<GenTooMan>
could the lock signal be dysfunctional and it's actually outputting 25MHz?
<tnt>
It is outputting something at least close to 25 MHz but I have no way to check the stability other than the led blinks roughly at the right rate.
shapr has joined ##openfpga
<GenTooMan>
Oh... no frequency counter
<GenTooMan>
this is just my opinion I despise most of lattice PLL designs but I am use to fractional PLL used for RF synthesis, so that might be just partial bias. I prefer to have better control over the PLL output though. When dealing with audio, video and RF that control is rather necessary.
<daveshah>
I think the CrossLink NX PLL does have fractional feedback
<daveshah>
at least according to the user guide, I'm not sure if the Radiant wizard actually uses it
<flea86>
GenTooMan: Yeah, dunno why Lattice went backwards a bit with their ECP5 PLL (from say, MachXO2...)
<flea86>
daveshah: Good to see they put it back heh
<daveshah>
Also has spread spectrum mode which I think is new
<tnt>
At least the hyperram on my board seems to work fine so far. This is just using the simple tested from khubbard so it runs the actual hyperbus at sys_clk / 4 so it's pretty slow. (here I has sys_clk = 175 MHz so hyperram at 43.75 MHz vs its 166 Mhz max ...)
<tnt>
Now onto writing a proper controller :p
flea86 has quit [Ping timeout: 265 seconds]
lutsabound has quit [Quit: Connection closed for inactivity]
flea86 has joined ##openfpga
vup2 has quit [Quit: No Ping reply in 180 seconds.]
anuejn has quit [Quit: No Ping reply in 180 seconds.]
anuejn has joined ##openfpga
gruetzkopf has quit [Remote host closed the connection]
vup has joined ##openfpga
gruetzkopf has joined ##openfpga
<rvense>
cr1901_modern: is it correct that you added the hx8k evb to litex-buildenv? do you remember which cpu you tested with? i can only get lm32 to work, and only an old commit
<cr1901_modern>
rvense: For various real life reasons I haven't been closely following litex-buildenv for about a year so I can't really help port it immediately
<tnt>
daveshah: oh, I didn't realize the constant current driver in the UP5k have TRIM inputs as well (like the OSC)
<daveshah>
Oh, hmm, I'm not even sure if I've noticed those before
<daveshah>
Don't think they are in icebox or nextpnr anyway