jevinski_ has quit [Read error: Connection reset by peer]
jevinskie has joined #yosys
<keesj>
FOSDEM anyone?
jevinski_ has joined #yosys
jevinskie has quit [Ping timeout: 245 seconds]
emeb_mac has quit [Quit: Leaving.]
NPHK has quit [Ping timeout: 240 seconds]
proteusguy has quit [Remote host closed the connection]
dys has quit [Ping timeout: 246 seconds]
proteusguy has joined #yosys
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 244 seconds]
rohitksingh has joined #yosys
TFKyle has quit [Ping timeout: 240 seconds]
goatama has left #yosys ["Leaving"]
TFKyle has joined #yosys
rohitksingh has quit [Ping timeout: 250 seconds]
citypw has quit [Ping timeout: 268 seconds]
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 252 seconds]
rohitksingh_work has quit [Quit: Leaving.]
keesj has quit [Ping timeout: 246 seconds]
fsasm has joined #yosys
rohitksingh_work has joined #yosys
citypw has joined #yosys
sxpert has joined #yosys
rohitksingh has joined #yosys
<sxpert>
now that I have tested my module with iverilog, how would I run yosys on it ?
<daveshah>
sxpert: You will want to do something like `yosys -p "synth_ice40 -top top -json design.json" design.v`; `nextpnr-ice40 --up5k --json design.json --pcf design.pcf --asc design.asc`; `icepack design.asc design.bin`
<daveshah>
changing the name and device type as appropriate
<sxpert>
they just received a batch as we speak, you may be lucky
<MoeIcenowy>
oh official EVN... they're usually quite expensive...
<daveshah>
the 85F-EVN is very good value
<sxpert>
200€ a piece. not bad
<sxpert>
well it's a 45F, but that's the same as 85F...
<MoeIcenowy>
for iCE40 I choose to do a UP5K board by myself (currently pending due to Chinese New Year) because all existing boards are too expensive (maybe except UPduino)
<MoeIcenowy>
but I heard that UPduino doesn't feature an onboard crystal oscillator
<emeb>
It doesn't
<emeb>
got one right here
<sxpert>
what's it using then ? integrated pll thingie ?
<emeb>
on-chip 48MHz RC osc
<sxpert>
ah
<emeb>
or 10kHz low freq osc if you want
<sxpert>
good enough if you're not too timing sensitive
<MoeIcenowy>
FleaFPGA seems interesting
<emeb>
yep
<emeb>
I've done a few personal boards w/ LP4K/UP5K (pin compatible)
<emeb>
they're pretty easy to do
<emeb>
Don't copy UPduino design tho - there are some problems with the power supply circuitry.
<sxpert>
ah
<sxpert>
good to know
<emeb>
and grounding isn't ideal. It works but it could be a lot better.
<MoeIcenowy>
emeb: what problem?
<MoeIcenowy>
lack of decoupling capacitor on VCCPLL?
<emeb>
MoeIcenowy: That's a big one.
<MoeIcenowy>
emeb: I found it's fixed in 2.0
<MoeIcenowy>
I currently put a 104 and a 106 for VCCPLL on my board
<emeb>
Yep. Plus diode/cap reversed on Vpp ckt
<emeb>
didn't put cap on FPGA side of diode.
<MoeIcenowy>
emeb: Y?
<emeb>
why what? I don't know why upduino did it that way, but it doesn't provide good bypass due to high impedance of diode on half wave of ripple.
<MoeIcenowy>
I think the cap should be the FPGA side, not the VCC3V3 side...
<MoeIcenowy>
from my (limited) experience cap should be near the chip...
<emeb>
Correct
<emeb>
but on upduino it's not.
<MoeIcenowy>
oh sorry
<MoeIcenowy>
I misread your sentence
<MoeIcenowy>
you mean "UPduino didn't put cap on FPGA side"
<emeb>
yes.
<MoeIcenowy>
I read it as "Don't put cap on FPGA side"
<MoeIcenowy>
checked... not fixed on UPduino 2.0
<emeb>
Sorry for confusion.
<MoeIcenowy>
emeb: no sorry
<MoeIcenowy>
just my mother tongue is not en
<emeb>
I'm sure it's better than my understanding of your language. :)
* emeb
speaks toddler-grade german plus some spanish. :P
<MoeIcenowy>
at least they're all Indo-European
<emeb>
I suspect I'd be useless with anything that didn't use roman alphabet.
<MoeIcenowy>
BTW what's VPP_2V5 for?
<MoeIcenowy>
programming the NVCM?
<emeb>
That would be my guess.
<daveshah>
It's also needed for a few other bits and pieces
<MoeIcenowy>
(to be honest I do not like any kind of OTP
<daveshah>
In particular trimming for the oscillators is read from NVCM at boot
<MoeIcenowy>
(I do not like irreversible things
<MoeIcenowy>
daveshah: oh
<daveshah>
If Vpp_2V5 is bad then the oscillator frequency will be way off
<emeb>
Good for saving pennies on high volume stuffs
<emeb>
but it would be nice if it could erase
<emeb>
daveshah: didn't you figure out that osc can be tuned via the FPGA fabric?
<daveshah>
Yes, it can be
rohitksingh has quit [Ping timeout: 240 seconds]
<emeb>
would be interesting to make FLL with that.
<emeb>
use 1PPS from GPS or something.
rohitksingh has joined #yosys
Cerpin has joined #yosys
<ZipCPU>
emeb: Been there, done that, it's not all that hard. Requires a bit of a tracking loop. I used a filter together with a 2nd order loop to track both phase and frequency. It works fairly well.
<tpb>
Title: GitHub - ZipCPU/openarty: An Open Source configuration of the Arty platform (at github.com)
<emeb>
ZipCPU: Yes - I've looked at your GPS-disciplined clock project before. IIRC though it's using a fixed external clock and locking a divided down version of that by putting a control loop on the divider ratio. I'm talking about locking the on-chip RC oscillator of the UP5k by controlling the tuning word which is kind of a hidden parameter that Lattice doesn't give you easy access to.
<ZipCPU>
Yeah, okay, that's different. That actually takes updated hardware to do.
<ZipCPU>
;)
<ZipCPU>
On the other hand, you can use the GPS schooled logic to create a GPS-disciplined oscillator ...
<ZipCPU>
(It'll jump a bit every second, as currently built....)
<emeb>
It's just a wild idea. I don't know how easy it would be to control that tuning parameter in realtime - just something that jumped into my brain when daveshah: mentioned the tuning param was available.
<emeb>
On the other hand - if it is available then it could be used to lock a USB device to the SOH pulse.
<ZipCPU>
Ooohh ... I definitely need to read more of the backlog ... logically controlling a tuning parameter based upon GPS input? That would be quite vascinating
<ZipCPU>
*fascinating
<emeb>
That's how the STM32F042 chip manages to get stable USB operation without an external crystal.
<emeb>
That would make it super cheap to put USB onto a UP5K part.
<MoeIcenowy>
emeb: emmm on UP5K osc can sync to external signal?
<emeb>
MoeIcenowy: it's not a normal feature of the oscillator, but daveshah found that there are hidden hooks on the IP core that could be used for that.
<MoeIcenowy>
hidden ;-)
<MoeIcenowy>
only utilizable with IceStorm? ;-)
<emeb>
MoeIcenowy: Probably.
rohitksingh has quit [Ping timeout: 250 seconds]
leviathanch has quit [Remote host closed the connection]
danieljabailey has quit [Ping timeout: 268 seconds]
dys has joined #yosys
<emeb>
Trying to build nextpnr on Fedora 28 using instructions at http://www.clifford.at/icestorm/ and cmake -DARCH=ice40 is failing due to not finding Boost::Python
<emeb>
I did install all the listed prereqs as defined in the instructions.
m4ssi has quit [Remote host closed the connection]
<emeb>
I also installed boost-python3 and boost-python3-devel but cmake is still unhappy
<emeb>
oh wait - looks like it's just kicking out warnings now.
<emeb>
OK - all happy. Nevermind. :P
<emeb>
(might want to add the boost-python3 and boost-python3-devel dependencies to the list on the icestorm page though)
fsasm has quit [Ping timeout: 240 seconds]
<emeb>
So, trying out nextpnr on my up5k SDR front-end. It seems to chew through it OK, but the critical ADC input path isn't meeting timing.
<emeb>
I see that nextpnr doesn't use a .sdc file to specify clock freq goals but instead has a single freq argument on the cmd line. Is this the only knob available to turn?
<emeb>
clock constraints successfully added. unfortunately that didn't improve the final results very much. This is a pretty challenging design though - lots of giant adder trees for a CIC decimator that need to run at 50MHz.
<ZipCPU>
Why do you need an adder tree for a CIC decimator?
<ZipCPU>
You should be able to build that with just 3 adds as I recall
<ZipCPU>
... for any decimation
<daveshah>
You can try adding -relut to Yosys' synth_ice40 command
<daveshah>
This can improve QoR for some carry chain structures
<ZipCPU>
Sure, you could, but if you are fighting with the hardware on this one then you are designing the CIC wrong
<ZipCPU>
CIC's should be simple to implement
<ZipCPU>
(Overflow helps)
<tmeissner>
Hi everone
<tmeissner>
I'm at FOSDEM this eekend
<ZipCPU>
Afternoon, tmeissner!
<tmeissner>
Anyone also there from this group?
<daveshah>
Hey tmeissner, I'll be there too!
<tmeissner>
Yeah, I saw that you have a talk in the EDA room :)
<ZipCPU>
emeb: Are you at a University at all? Check out frederic harris' book on "multirate signal processing"
<tmeissner>
I think I'm in this room to hear some of the talks
<emeb>
ZipCPU: I'm not at a uni but I've got a copy of that book
<emeb>
ZipCPU: perhaps "tree" was the wrong term - adder chains.
<ZipCPU>
No, that's the right term for the wrong implementation
<tpb>
Title: Implementing the Moving Average (Boxcar) filter (at zipcpu.com)
<ZipCPU>
You shouldn't need any adder trees or adder chains at all--CICs are *REALLY* easy to implement
<ZipCPU>
If you check out the boxcar.html page on zipcpu.com, check out figure 3 which shows what I'm talking about
<ZipCPU>
Instead of needing to add N values together to get the next output, you add the difference of the new value with the old value that falls off the end
<emeb>
ZipCPU: yes - nothing fancy about the math in my CIC.
<emeb>
But the wordlenghts are large
<ZipCPU>
?? How big?
<emeb>
14-bit inputs, 8 bits growth per stage, 4 stages, so 46 bits on the output of the integrator.
<emeb>
I've tried it with truncation and without
<ZipCPU>
What happens with truncation?
<emeb>
throw away some lsbits between the integrator and comb stages.
<emeb>
just to reduce the complexity of the comb stages.
<ZipCPU>
Why not cascade the CICs at different rates, to keep the bit widths down?
<ZipCPU>
Oh, another question, how fast does this need to operate?
<tpb>
Title: GitHub - daveshah1/nextpnr: nextpnr portable FPGA place and route tool (at github.com)
<daveshah>
Then rebuild
<emeb>
on it
<daveshah>
I've seen this give results within 5-10% of the Lattice tools
<daveshah>
But large adder chains might be a bit of a weak spot atm
<ZipCPU>
emeb: Having looked at your code, I take back my initial conclusion(s) ;)
<emeb>
ZipCPU: :)
<ZipCPU>
You should be able to drop bits before integration tho ... there's no reason why you need to go into there with 10 bits if you don't want 46 bits out
<emeb>
ZipCPU: well, in my experience it's good to start with the best dynamic range you can get, and I've got a 14-bit ADC.
<ZipCPU>
Yeah ... I can understand that perspective completely
<emeb>
I've got a version of this DDC running on a Spartan 6 with 100MHz 14-bit ADC inputs and a hardware AGC on the output of the CIC that gives me a nice bit of dynamic range.
<emeb>
but in the UP5k version I just carry 16-bits output and do the AGC in software
<emeb>
daveshah: OK - checked out your branch, rebuilt and reran on my design. Didn't make much difference on the timing.
<emeb>
I'd be happy to bundle this up as a testcase if you'd like.
<daveshah>
That would be great
<daveshah>
I think this is probably more of a synthesis than nextpnr issue
<emeb>
Could well be
<daveshah>
At the moment carry chains prevent a number of logic optimisations from working properly
<daveshah>
We are investigating alternative ways of interfacing with abc to improve this
<emeb>
sounds hairy
<emeb>
daveshah: testcase built - where should I send it?