genii has quit [Remote host closed the connection]
_whitelogger has joined ##openfpga
dj_pi has quit [Ping timeout: 244 seconds]
<m_w>
can the ECP5 drive the AD9361 transceiver?
<m_w>
daveshah,??
<flea86>
m_w: I am not he, but a quick study of the AD9361 datasheet tells me yes it would..
<m_w>
flea86, do I need the fancier one with the serdes?
<m_w>
guessing not
emeb_mac has quit [Ping timeout: 244 seconds]
<flea86>
m_w: You probably need to read up a bit more about how superheterodyne radios work :)
<m_w>
flea86, yeah sounds like rocket science
<m_w>
just considering what I could do with this new ecp5 board I am working on
<flea86>
Nah, not necessarily rocket science from a purely hardware perspective, but more from the DSP/sw side after direct conversion step has occurred.
<flea86>
Also, cool :)
OmniMancer has joined ##openfpga
<tnt>
Ohhh #268 is pretty bad.
m_w has quit [Quit: Leaving]
m4ssi has joined ##openfpga
<daveshah>
m_w: yeah any ecp5 is fine, it just needs regular single ended or diff io
<daveshah>
tnt: yup looks like a missing validity check
<daveshah>
Shouldn't be hard to fix
<tnt>
There doesn't seem to be much validation for conflicts in SB_IO. Sod far it relies on routing throwing up an error when trying to route two wires to the same sink.
<daveshah>
Yes, and the router considers disconnected signals as 1'bx (and I'd rather not change that) so doesn't care in this case
<daveshah>
Much better to fix in validity checking for sure, that way it will also place things correctly if unconstrained
<tnt>
yeah, I was thinking of adding that to isValidBelForCell
<tnt>
we already check the complement cell for LVDS validity
<tnt>
daveshah: I'm wondering if having sort of a 'errno' style variable that would point to a message describing the last conflict encoutered by isValidBelForCell would be useful. So that we could provide more meaningful error messages of what the damn conflict is.
<daveshah>
So long as it doesn't add any significant overhead (these functions need to be as fast as possible) that is a good iea
<daveshah>
*idea
<daveshah>
Another option is to re-run it with a flag set that causes it to print info about the conflict
<cr1901_modern>
"For more descriptive error info, run with these parameters: --seed $whatever --verbose"
<daveshah>
This is an internal thing, not a cmdline thing
<tnt>
yeah, that function is called thousands (or way more) times, but most time it's not fatal if it's not valid. SA is basically trial and error ...
<daveshah>
ie adding something like "bool verbose = false" to isValidBelForCell and isBelLocationValid
rohitksingh_work has quit [Read error: Connection reset by peer]
OmniMancer has quit [Quit: Leaving.]
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 252 seconds]
X-Scale` is now known as X-Scale
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
duck2 has joined ##openfpga
emeb has joined ##openfpga
wpwrak has quit [Ping timeout: 255 seconds]
wpwrak has joined ##openfpga
unixb0y has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
kristianpaul has quit [Quit: WeeChat 1.9.1]
kristianpaul has joined ##openfpga
kristianpaul has quit [Client Quit]
kristianpaul has joined ##openfpga
_whitelogger_ has joined ##openfpga
_whitelogger has quit [Ping timeout: 240 seconds]
whitequark has joined ##openfpga
gsi__ is now known as gsi_
whitequa1k has joined ##openfpga
whitequa1k has quit [Client Quit]
unixb0y has quit [Ping timeout: 246 seconds]
unixb0y has joined ##openfpga
rohitksingh has joined ##openfpga
Laksen has joined ##openfpga
wren6991 has joined ##openfpga
<wren6991>
Sorry for the comment after merge on nextpnr, genuine mistake. I had the PR tab open and was trying it out.
<wren6991>
I think there is some ambiguity between: CLKE disconnected, CLKE connected to a net with no drivers, CLKE connected to 1'b1
<wren6991>
All of which (I think) give the same bitstream and the same physical result, but are now logical conflicts with one another
<tnt>
CLKE connected to 1'b1 will result in a different bitstream.
<tnt>
nextpnr will actually route it to a LUT outputing '1'.
<wren6991>
Ah that makes sense then. Is that intentional?
wren6991 has quit [Quit: Page closed]
wren6991 has joined ##openfpga
rohitksingh has quit [Ping timeout: 268 seconds]
<tnt>
wtf ... icecube2 will just silently "relocate" the IO if it can't satisfy the shared pin constraint !?!?s!
<tnt>
"W2724: IO constraint specified on pin '16' is infeasible. Ignoring the constraint"
<tnt>
But interestingly it doesn't complain when having one enable connected to 1'b1 and the other connected to something ...
<wren6991>
Haha, had to use icecube for a uni project. Spent an evening trying to install it, and then ended up building yosys + arachne for the first time
<wren6991>
Oh that's weird. Any idea what the actual physical behaviour is? Clifford's bitstream docs seemed to suggest you can't do that
<tnt>
No idea of the physical behavior no.
<wren6991>
maybe they do the same as #268 :D
<tnt>
I think they do ...
<tnt>
because comparing the generated .asc file for both case yield the same content ...
Maya-sama has joined ##openfpga
Laksen has quit [Read error: Connection reset by peer]
Miyu has quit [Read error: Connection reset by peer]
Laksen has joined ##openfpga
cr1901_modern has quit [Ping timeout: 250 seconds]
<tnt>
wren6991: I'm actually wondering if a net with no driver isn't mapped to 0.
Maya-sama is now known as Miyu
<tnt>
yup, looks like it is.
<wren6991>
Yeah you're right, it is.
<wren6991>
doh concurrency error. I just checked quickly on an HX8k board, don't know the nextpnr codebase.
<tnt>
if you want it to default to '1' you need to put a weak '1' driver as the default in your wrapper.
<wren6991>
Oh, didn't realise yosys would synthesise those :)
<tnt>
... well ... it doesn't, I was optimistic :p
<wren6991>
I've fixed my RTL problem by putting a clock enable on my DDR wrapper as well as my DFFE wrapper, so I can connect both SB_IOs to a 1'b1 LUT. It's all good :)
<wren6991>
What nextpnr does now is fine, but maybe a little surprising
<wren6991>
undriven net is debatable but I .CLOCK_ENABLE(1) vs an SB_IO without connecting clock enable seem logically the same (and nextpnr was okay with this prior to #270)
<wren6991>
*but I think
<tnt>
it was 'ok' because it wasn't checking anything :p
<tnt>
thing is nextpnr currently has no clue of the 'default value' of ports when they are not connected.
<wren6991>
Yes but it was consistent with simulation and didn't refuse to build; the presence of the 1'b1 LUT seems like a nextpnr (or maybe yosys?) implementation detail
<wren6991>
Ah okay
<wren6991>
So it would probably require a fair bit of code motion for a simple change, got you
<daveshah>
In addition to possibly dropping the 1'b1 in nextpnr the sim model should probably be fixed to treat disconnected CE as 1'b1
<tnt>
and so when you assign explicitely a 1'b0 or a 1'b1 to a port, it will route GND and VCC nets (i.e. two luts will be programmed to output always 0 and always 1) and route them to the port.
<wren6991>
daveshah: I will file a PR for ice40 simlib soon anyway, after finding out its actual behaviour from that thread with whitequark. I can just throw in a pull1 assignment or something?
<tnt>
daveshah: I was also thinking that (1) 'x' in the input json should be treated as 'no connection'. (2) any net that doesn't have any users should also be stripped (to avoid everytime having net == nullptr || (net->users.size() == 0) every place).
<daveshah>
Yeah, or just something like ce_pu = (CLOCK_ENABLE === 1'b1 || CLOCK_ENABLE === 1'bz)
<daveshah>
Agree about 'x'
<daveshah>
I think stripping should be fine too
<tnt>
worst case we can add a property to special nets like 'keep' if some need to be kept around for some reason.
genii has joined ##openfpga
cr1901_modern has joined ##openfpga
<emeb>
tnt: my 6502/BASIC project now has hooks into MS BASIC so that the LOAD/SAVE functions read & write to the SPI flash. Was fun getting that working.
* emeb
is now permanently damaged by studying Bill Gates' assembly code.
<tnt>
emeb: oh nice. I saw you added sound output as well ? :)
<emeb>
tnt: yeah - the sound output is pretty fun to fiddle with. make lots of weird noises. Sigma Delta modulation is surprisingly good and very simple to implement.
<emeb>
(definitely not "audiophool" quality, but decent for 1 pin + R/C lowpass)
<tnt>
you could add digital predistortion to compensate some of the non-ideal effects :p
<emeb>
tnt: no doubt. While researching I came across a few different approaches to that.
* emeb
did a lot of digital predistortion research in a previous life.
<tnt>
Is there anyway to tell te SA placer to try for a longer time ?
<wren6991>
You can just patch the temp profile and rebuild
<wren6991>
I tried this, but was disappointed with results.
<wren6991>
You're better off kicking off many builds with random seeds.
<wren6991>
I made build time around 10x longer by making temperature ramp down less aggressive, but this almost always gave worse results than 10 random seeds with default profile
<wren6991>
this was around a 2000-LUT design on an HX8k
<wren6991>
(oh and seed-sweeping can be parallelised! :) )
cr1901_modern1 has joined ##openfpga
<whitequark>
i feel like once you reach this point what you need is more registers, always
<whitequark>
and what we collectively need are languages that make it easier to add more registers
<tnt>
well when there is a feedback path you can't just add registers ...
cr1901_modern has quit [Ping timeout: 250 seconds]
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined ##openfpga
<wren6991>
whitequark: my critpath is memory rdata -> instruction decode -> jump address -> memory address
<wren6991>
so more registers would give strictly worse performance in tight loops, without some other far-reaching changes
<wren6991>
meanwhile I can get an extra 5~10% (!!) performance with a little seed sweeping, and that stacks on top of any architectural improvements :)
<wren6991>
Agree on languages though
<whitequark>
nondeterministic build process is bad enough
<whitequark>
nondeterministic build process that may never succeed is far worse
<whitequark>
just say no :p
<tnt>
yeah similar case here. the histogram shows I only have 10-20 paths that are very critical, and with a good seed those actually go decently higher than what I need, it's just I'd like the placer to focus on those first :p
<tnt>
so far my solution for those case has been to manually lock the cells at the "right place" but that's a bit tedious :p
<wren6991>
whitequark: I don't currently do this in normal makefile, and if I did, it would be fixed count + take highest, not iterate until threshold!
<wren6991>
It's just moving and tightening the distribution by throwing processing time at it
<wren6991>
which is similar to what you do by increasing SA time, except this seems to work better (I haven't actually done the stats analysis though)
<wren6991>
More importantly, I need to justify the ryzen 1700 I bought a couple of years back :p
<tnt>
lol
<whitequark>
lol
<tnt>
I need to try out the VexRiscV see if I get better results than the picorv32.
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 245 seconds]
<emeb>
whitequark: in the past I used a language called "Module Compiler" that allowed a distinction between registers that were for pipeline / timing management and those which actually carried true state of the system.
<emeb>
then during timing driven synthesis it would add pipes to make timing without screwing up state.
<wren6991>
VexRiscV seems to be just an insanely tight design
<wren6991>
Itching to do some small processors in nMigen, that pipeline class seems like a neat idea
<emeb>
Module Compiler was eventually swallowed whole by Synopsys and now is no longer to be seen.
<whitequark>
emeb: i feel like nmigen can/should offer something like that
<emeb>
whitequark: I suspect that the present partitioning of the design flow of migen -> verilog -> yosys -> nextpnr my hinder that, since proper pipelining needs up-front knowledge of the resulting timing and that doesn't happen until nextpnr now.
<whitequark>
emeb: I am thinking about manual feedback here
<whitequark>
for one that would work with any toolchain
<emeb>
so you'd wrap the whole chain in a script that gathered the final timing and fed back to the front end?
<wren6991>
Even just being able to manually iterate much faster based on timing reports would be super valuable
<whitequark>
^ that
<wren6991>
Like in the VexRiscV article, sourcing your multiplier result from a different pipe stage is literally a one-line change
<wren6991>
vs Verilog where it is 50 lines in 5 files
<wren6991>
All the interlocks, bypassing and flops are added automatically based on your datapath schema
<emeb>
well sure, stuff that's designed at a very high level of abstraction like VexRiscV will be easier to tweak since you don't have all those artificial boundaries that come with low-level implementation by humans.
<wren6991>
If your design is compatible with the model of "add flops til it's fast" can't you just stick empty pipe stages on the end and retime them through? Seems like retiming follows similar rules to Module Compiler's idea of state vs datapath, and has similar limitations
<emeb>
wren6991: that's eventually what Synopsys allowed w/ normal HDLs.
<wren6991>
You are losing the benefit of this being done automatically based on timing feedback I guess
<wren6991>
ohh cool!
<emeb>
the downside of that is the overall latency is still hardcoded, so if you add N pipes at the end and then let the tool distribute them, you may end up with more pipes than you need.
<emeb>
so you have go back and remove them. MC would know up front how many were needed to meet the goal.
<emeb>
overall less iteration
<whitequark>
it seems like you could mark pipeline registers so that nextpnr knows it can duplicate them, no?
<wren6991>
I guess that is valuable for a large design where your turnaround is measured in hours or days
<tnt>
you can always duplicate registers if that helps your routing/placement ... both copies will output the same value.
<whitequark>
no, i mean duplicate and connect in series
<whitequark>
not parallel
<tnt>
oh. retiming is done in yosys, not in nextpnr.
<tnt>
and really I find a tool that would 'automagically' increase my latency for me to be a pretty bad idea ...
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
<tnt>
making it easy for me to do it, sure. Doing it for me entirely with potentially per-build different results ... no so much.
<emeb>
tnt: yes - having the latency shift uncontrollably wouldn't be good. But knowing early in the design process what it *can* be is good.
<whitequark>
tnt: hmm, point
<daveshah>
I have done pipeline insertion during HLS for a video application very successfully
<daveshah>
This was very much a case where any latency between 1 and 10000 would have been fine
<daveshah>
Need to be a bit careful to ensure latency remains equal at all points in data path
<daveshah>
I think this would be quite tricky for nextpnr without good annotation from Yosys
stefanct has quit [Read error: Connection reset by peer]
stefanct has joined ##openfpga
stefanct has joined ##openfpga
stefanct has quit [Changing host]
genii has quit [Remote host closed the connection]
flea86 has joined ##openfpga
Bike has joined ##openfpga
finsternis has quit [Remote host closed the connection]