<tpb>
Title: GitHub - akzare/Async_FIFO_Verification: Presents a verification use case for a typical Asynchronous FIFO based on Systemverilog and UVM. (at github.com)
<mattvenn>
ZipCPU_: I didn't really understand your tweet about the 32bit multiplies
<mattvenn>
In my FFT implementation I just did a <= b * c;
<mattvenn>
which seemed to work OK
<mattvenn>
is it that you can write a more optimised multiplier than yosys can infer if you know what type of numbers the multipy will be handling?
<daveshah>
mattvenn: Yosys will always infer a single-cycle multiply if you do that
<daveshah>
ZipCPU_ wanted a multi-cycle multiplier
<mattvenn>
so that it could fit with a pipeline or some other multi cycle logic?
<mattvenn>
or uses less LUTs?
<daveshah>
in this case, the idea is one value is only needed every 32 cycles (for example), so far fewer LUTs are needed compared to a full single cycle multiplier
dys has joined #yosys
dxld has quit [Quit: Bye]
dxld has joined #yosys
leviathan has joined #yosys
dys has quit [Ping timeout: 256 seconds]
dys has joined #yosys
develonepi3 has joined #yosys
quigonjinn has joined #yosys
gyroninja has quit [Ping timeout: 255 seconds]
jwhitmore has joined #yosys
seldridge has joined #yosys
gyroninja has joined #yosys
seldridge0 has joined #yosys
seldridge has quit [Ping timeout: 240 seconds]
promach_ has joined #yosys
seldridge0 has quit [Ping timeout: 260 seconds]
emeb has joined #yosys
maikmerten has joined #yosys
<maikmerten>
hi there, I'd like to use the SRAM on my icoboard, for which I'd need a tristate in/outputs for the data lines. Some while I ago, I think I read that yosys only has limited tristate support. Is there some hint on what "limited" means in this case? I'd like to avoid instantiating the I/O manually if possible.
develonepi3 has quit [Remote host closed the connection]
<daveshah>
It is generally best to instantiate IO if you want anything fancy
<daveshah>
The most basic tristate pattern hopefully works, a fix was even pushed a few hours ago
seldridge0 has joined #yosys
seldridge0 has quit [Ping timeout: 240 seconds]
GuzTech has quit [Quit: Leaving]
xerpi has joined #yosys
seldridge0 has joined #yosys
xerpi has quit [Remote host closed the connection]
seldridge0 has quit [Ping timeout: 265 seconds]
<maikmerten>
daveshah, thanks
<maikmerten>
completely unrelated: does anybody know how iCE40 HX devices compare against entry-level stuff from Altera (e.g., Cyclone IV) or Xilinx (Spartan?) speed wise? The RISC-V SoC I'm developing for fun has an icetime estimate of somewhere between 49 to 56 MHz, depending on placement luck. A similiar design usually went to ~ 80-90 MHz in Cyclone IV and I wonder how the FPGAs come into play here.
pie_ has joined #yosys
<mattvenn>
daveshah: thanks
<sorear>
icestorm is known to be a fair amount worse than lattice tools at timing optimization
<maikmerten>
as far as I can see it's not timing driven, just tries to keep routes short - which of course strongly correlates
<daveshah>
maikmerten: the problem is, different routes have different "importances" in timing
<daveshah>
if a route is part of a timing path with lots of cells, it must be shorter than one in a path with few cells
<awygle>
arachne also doesn't prioritize the longest route or anything like that
<awygle>
i wonder if switching from HPWL to QWL would give better timing results...
<maikmerten>
daveshah, indeed - yeah
<daveshah>
awygle: it's something to investigate once we have a better framework for doing these kinds of experiments
<awygle>
daveshah: yup. although hopefully we can use better models at that point.
<awygle>
QWL is a one-function change to arachne
<awygle>
(to first order anyway)
<maikmerten>
just to be clear: I'm *very* happy with the whole icestorm experience and the synthesis results are more than just fast enough for my hobby applications
<maikmerten>
also the tools are fast... from "make clean" to a bitstream file including timing analysis in < 30 seconds on my Ryzen 2700
<awygle>
maikmerten: glad to hear :) you didn't come off as unhappy, we just always want things to be better
<maikmerten>
:-)
<maikmerten>
as for the hardware itself: iCE40 seems to a simple, yet reasonably "fresh" design on 40nm, so at least from that vantage point it shouldn't be at an disadvantage compared to e.g., Cyclone IV
<awygle>
my understanding is that the altera LABs are much more powerful, and that the ice40 is generally optimized for power consumption rather than speed. but i'm not familiar with cyclone iv at all.
<maikmerten>
yeah, seems that Lattice is pushing the power aspect most
<awygle>
this is most clear with the UltraPlus, which is ~half the speed of the LP
<maikmerten>
I'd guess they're pushing that as "glue logic" for mobile applications
ZipCPU has joined #yosys
digshadow has quit [Ping timeout: 248 seconds]
leviathan has quit [Read error: Connection reset by peer]
<maikmerten>
(code: https://pastebin.com/hJUDGMtg - completely untested, of course. Some weirdness because of my data bus being 8 bits wide, while the SRAM is 16 bits wide)