<daveshah>
Yosys only supports this if the block is named
<daveshah>
ie you have :somename after begin
<sxpert>
I see
<sxpert>
come to think of it, it seems that there are a few combinations in the opcodes, so I could make a few wires ...
<sxpert>
and reuse them elsewhere
<sxpert>
should generate less logic overall, I guess
<daveshah>
Maybe, but many of these cases will be dealt with by opt_merge
<sxpert>
will make it nicer to read too ;)
AlexDaniel has joined #yosys
tinyhippo has joined #yosys
tinyhippo has left #yosys ["WeeChat 2.3"]
AnkurA has joined #yosys
<AnkurA>
Hey all, not able to do synthesis with .plib provided by foundry
<AnkurA>
any idea if .plib cannot be used?
<daveshah>
Yosys supports Liberty libraries for ASIC synthesis, is that what a .plib is?
<AnkurA>
any other ways to do it if the foundry has not provided .lib liberty file?
<AnkurA>
.plib is some physical library file
<AnkurA>
excepth, various other files are provided like .db, .sef, .nldm, etc.
<AnkurA>
except .lib I meant
<daveshah>
Many of these files are proprietary
<daveshah>
It looks like the plib might be a heavily extended Liberty, in which case it might be possible to modify Yosys to skip over the bits it can't use
<AnkurA>
Found .lib in nldm folder
<AnkurA>
thanks.
AnkurA has left #yosys [#yosys]
<sxpert>
daveshah: soon there will be an opensource library for opensource asics with opensource process, I understand
<daveshah>
LibreSilicon?
<sxpert>
yeah
<sxpert>
that looks pretty interesting
<daveshah>
other than the blockchain stuff
<sxpert>
what blockchain stuff ?
<daveshah>
> By using a blockchain solution in order to track the added value from the work of every contributor, without any human intervention required, it is ensured that everyone is being payed a fair price for the work and time she or he has invested into developing an ASIC or IP block. Manufacturing potential can be reported on a market place where customers can put up orders. The result will be something like a crypto exchange
<daveshah>
just without speculation, a way for people who want to buy chips and people with a basement containing a clean room to find each other. This becomes possible with our free semiconductor manufacturing process standard which allow reproducible results with varying setups.
<sxpert>
ah.
<sxpert>
not really interested by that part
<sxpert>
the silicon manufacturing bit is the important part here
<sxpert>
guess they needed "Blockchain" somewhere in the blurb to get financing
cr1901_modern has quit [Ping timeout: 250 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
<corecode>
lol blockchain
<sxpert>
it's one of those magic buzzwords to get money from know-nothing capitalists. can be considered as a nop
cr1901_modern has joined #yosys
rohitksingh has joined #yosys
<cr1901_modern>
daveshah: Do you have a moment to hear about our lord and savior blockchain?
jevinskie has joined #yosys
<somlo>
"If you think blockchain is the solution to your problem, you don't understand blockchain. And, you don't understand the problem"
<sxpert>
so...
<sxpert>
I think I'm getting somewhere
<sxpert>
guess I should be splitting this ALU thing with the registers into a separate module
<sxpert>
will try that later
<sxpert>
feels like major surgery though
<sxpert>
daveshah: what does "Clock '$glbnet$ph1' has no interior paths" means ?
<daveshah>
That means there are no paths between two registers both clocked by ph1
<daveshah>
Therefore a Fmax is not applicable
<daveshah>
however, max delays to/from other clock domains may be printed
<sxpert>
is that a problem ?
<daveshah>
Probably not
<sxpert>
ok
<daveshah>
Are you expecting all the registers clocked by ph1 to drive and be driven by registers in other domains?
<sxpert>
nope
<sxpert>
I'm actually trying to isolate things into their own domain
<sxpert>
one at a time
<daveshah>
That sounds dangerous
<sxpert>
hmm ?
<daveshah>
Good practice is to have as few clock domains as possible
<daveshah>
In many cases, everything except IO belongs in a single design
<daveshah>
*domain
<sxpert>
well, ph[0-3] are derived from a common clk
<sxpert>
however, on posedge, the phase will not be stable
<sxpert>
or is the logic happening before the clock edge ?
<sxpert>
ZipCPU: link above is most enlightening
<ZipCPU>
You mean the one I wrote?
<sxpert>
yeah
<ZipCPU>
Thanks!
<sxpert>
still, I'm puzzled by how this all works
<ZipCPU>
How so?
<sxpert>
all the logic described in the "always @(posedge clk)" block, is combinatorial logic and the clk controls all the touched flip-flops ?
<ZipCPU>
I'm not sure I follow yet
<sxpert>
I mean, that's how the fpga works inside ?
<ZipCPU>
Internal to an FPGA are LUTs, FFs, and wires to connect them all
<ZipCPU>
Many FPGAs group the LUTs and FFs together into logic blocks
<sxpert>
so what's inside the block is a bunch of luts, and the ff store whatever the luts have generated on the clk (up or down) signal
<ZipCPU>
The LUTs are your combinatorial logic, and are (often) immediately followed by FFs. The FF in the logic block can be bypassed, though, if you aren't interesteed in using it
<ZipCPU>
Yeah, something like that
<sxpert>
ok
<ZipCPU>
In addition, most FPGAs have some low-latency networks for clocks to help reduce clock skew from one part of the chip to another
<ZipCPU>
These low-latency networks, which are limited in number, tend to be fed to every logic block
<sxpert>
yeah, I had that part in the brain ;)
<ZipCPU>
The other part of the FF thing is that many FFs have CEs built into them
<ZipCPU>
Hence, your phase signals (once created) should be able to use the global routing networks, and then no additional logic at the FF
<sxpert>
I see
<ZipCPU>
Unless Yosys adds some more combinational logic, such as the FF only changes if A & B are true
<sxpert>
said phase signals should be "wire blah; assign blah = <something>;" ?
<sxpert>
the something being a function of counter
<sxpert>
?
<ZipCPU>
Well, you could say: wire [3:0] phase_ce; assign phase_ce[0] = counter[1:0] == 2'b00;
<ZipCPU>
Did you see my explanation of timing in terms of stalagtites and stalagmites
<ZipCPU>
It was on pages 10-13 of the tutorial lesson on debouncing (lesson 7) ... see http://zipcpu.com/tutorial
<ZipCPU>
If you use wire [3:0] phase_ce; assign phase_ce[0] = (counter[1:0] == 2'b00); your starting your design out in timing debt, and won't be able to do as much on the clock
<ZipCPU>
On the other hand, if you use: reg [3:0] phase_ce; always @(posedge i_clk) phase_ce[0] <= (counter[1:0] == 2'b00); your phase will be delayed by one clock tick (probably irrelevant) but you'll have more time to get things done based upon that value within your design
<sxpert>
ah. I see
<sxpert>
as long as the thing starts with phase_0 on reset
<ZipCPU>
That should be easy to verify
<sxpert>
yeah
<sxpert>
another Q I had was, is a monster case statement bad for timing ?
<ZipCPU>
It can be
<ZipCPU>
It isn't necessarily so though
<sxpert>
any known red-flags ?
<ZipCPU>
You mean with the monster case statement?
<sxpert>
yeah
<ZipCPU>
Some designs/designers use them often. I don't. Here's why ...
<ZipCPU>
The larger the case statement is, or the nested if, whatever, the more logic is required to compute every value
<ZipCPU>
My own design philosophy has always been about minimizing my logic usage count--hence the ZipCPU
<ZipCPU>
That usually forces me to move every register's definition/assignment into its own always block
<ZipCPU>
Have you seen my article on minimizing logic utilization?
<sxpert>
yeah, but guess I'll have to read again
<ZipCPU>
A lot of what I do is optimizing logic for those time periods where I don't care what a particular value is
<ZipCPU>
Another big part of what I do is to work very hard to minimize the logic used when that logic needs to be applied to lots of values
<ZipCPU>
For example, if (A) WORD <= I1 + I2; else if (B) WORD <= I1 ^ I2; else if ...
<ZipCPU>
Sometimes you can't get around it, like when building an ALU, but sometimes you can
<sxpert>
well, the ALU I built works in multiple phases, minimizing the work in each phase
<sxpert>
ph1: get the data, ph2: do calculation, ph3: write back
<ZipCPU>
What if the calculation takes longer? Such as a multiply or a divide?
<sxpert>
ph0 being request data from memory
<sxpert>
there's no such instruction ;)
<ZipCPU>
Are you only ever using block RAM? Never any flash memory?
<sxpert>
not at this time
<sxpert>
I was thinking of plugging some form of cache though, that would stall the processor while it accesses said flash on PC changes
<sxpert>
as I understand, flash works in a streaming fashion, as long as you request the next value
<ZipCPU>
You are working on an ECP5, right? I could never get the cache to fit on an iCE40
<sxpert>
yeah
<sxpert>
the original processor was 4Mhz...
<sxpert>
ZipCPU: how much cache were you trying to have ?
<ZipCPU>
I stripped it bare, down to two cache lines of 8 items each--still too much logic
<sxpert>
how big was that ice40 ?
<ZipCPU>
8k
<ZipCPU>
hx
<sxpert>
hmm
leviathanch has quit [Remote host closed the connection]
<sxpert>
so that's 8k luts ?
<ZipCPU>
7680 if I recall, but roughly 8k, yes
<ZipCPU>
They're 4-LUTs too, as opposed to the Xilinx 8-LUTs
<sxpert>
not much indeed
<ZipCPU>
(I'm not sure how big the LUTs are on the ECP5)
<sxpert>
I can see how that gets filled up pretty fast
<daveshah>
LUT4s, but with cascade muxes to combine to build larger LUTs
<daveshah>
Xilinx is LUT6 btw
<ZipCPU>
Thanks, daveshah!
<daveshah>
but also has muxes to build larger LUTs like ECP5
<ZipCPU>
Oohh, thanks, Looks like I mistyped that as 8-LUTs for the Xilinx chips, my bad
maikmerten has joined #yosys
<sxpert>
ZipCPU: 1 slice is 2 LUT4 and 2 FF
<ZipCPU>
daveshah would know that better than I. Are you asking regarding iCE40 or ECP5?
<daveshah>
sxpert: yes
<sxpert>
reading from the datasheet
<sxpert>
those lut4 have carry in and out too
<daveshah>
Yes, there's some carry logic in there
<sxpert>
doesn't say how many outputs those luts have though
<daveshah>
one
<sxpert>
ok
<daveshah>
in carry mode it's a bit more complicated
<daveshah>
is the model for the CCU2C carry primitive
* sxpert
bookmarks
emeb has joined #yosys
<emeb>
Trying to run a design thru nextpnr-ice40 and it fails with "ERROR: timing analysis failed due to presence of combinatorial loops, incomplete specification of timing ports, etc."
<daveshah>
emeb: could it be an inferred latch? try grepping the Yosys output for dlatch
<emeb>
daveshah: thx - will look.
oldtopman has joined #yosys
<emeb>
daveshah: found a few latches inferred in yosys - easily fixed w/ fully specified case. That did not eliminate the ERROR though.
<daveshah>
Is it possible there are other forms of combinational loop in there?
<daveshah>
If you just want to get rid of the error, run nextpnr with --ignore-loops
m4ssi has quit [Remote host closed the connection]
<emeb>
daveshah: it's possible - I'm using a 6502 IP core of unknown quality.
<daveshah>
In that case --ignore-loops is your best bet
<emeb>
Yes - thanks. that seems to let it run further, exposing some other interesting things to chase.
<ZipCPU>
You've only covered one half of the reset case
<emeb>
daveshah: also - thanks for the link to the SB_ lib yesterday. just read the chl log and spotted that.
<emeb>
which raises another question - is yosys able to infer the SB_SPRAM256KA ?
<daveshah>
No, it isn't
<daveshah>
atm Yosys doesn't support shared read/write ports of any kind
<sxpert>
ZipCPU: how would I go for that reset thing ?
<daveshah>
this also means it can't infer Xilinx/ECP5 true dual port RAM, only pseudo dual port (1R1W)
<sxpert>
ZipCPU: for now I expected to use the initial block, but that may not be the best solution
<ZipCPU>
sxpert: You want a structure such as: initial A <= 1'b0; always @(posedge i_clk) if (i_reset) A<= 1'b0; else A <= !A;
<emeb>
daveshah: OK, that makes sense. I was having trouble with inference so I just instantiated.
<sxpert>
ZipCPU: so as to debounce the reset ?
<sxpert>
or to buffer it somehow ?
<ZipCPU>
No
<emeb>
daveshah: and I was able to get my whacky 6502 thing to build - found a loop, broke it, now everyone is happy.
<daveshah>
:)
<ZipCPU>
To set your values both on a reset as well as following the reset
<emeb>
pro-tip - yosys does check for loops and warn about them. TIL. :P
<sxpert>
ZipCPU: what would A be used for ?
<sxpert>
initial does only apply on fpga bootup...
<sxpert>
I see
<ZipCPU>
I'm using A to avoid retyping all 9 of your assignments
<sxpert>
yeah right
<sxpert>
why !A though ?
<ZipCPU>
To avoid saying: clk_phase <= clk_phase + 1;
<sxpert>
should ah
<ZipCPU>
I was just trying to share the form of the solution
<sxpert>
and reset all other signals to 0
<sxpert>
I guess
<ZipCPU>
Well ... that's not quite a given
<ZipCPU>
The issue is that you want all of the en_* signals set to zero during the reset, and you then want en_bus_send set on the first clock after the reset
<ZipCPU>
(That was your requirement, not mine)
<sxpert>
ah right
<sxpert>
guess I can lose a step
<sxpert>
not a biggie
<sxpert>
so all to 0 would work
<sxpert>
ok, I have created a delayed reset enable too
<sxpert>
ZipCPU: yay, seems to work ;)
<sxpert>
now, I need to figure out the rest ;)
<ZipCPU>
o/
<sxpert>
there, removed all the old stuff (stored in a safe place)
<sxpert>
ZipCPU: the "generate if(blah)" is for optional stuff that may not get compiled in ?
<ZipCPU>
I use it for that purpose, yes
<ZipCPU>
blah must be a 1'bit parameter to make it work
<sxpert>
ok, won't need that ;)
<ZipCPU>
I suppose you could make it a localparam too ...
<sxpert>
or some `define
<ZipCPU>
I've had problems using `define's over the years
<ZipCPU>
I've used them on many projects
<sxpert>
ah
<ZipCPU>
The result usually ends up with something that's less capable, since it's harder to handle `define's in these projects
<sxpert>
generates some bitstring you can compare against
<chaseemory>
where current is an enum, and the rest are wires, and just concatted them together for each case as well
<sxpert>
suppose it allows for testing all cases of the enum ?
<chaseemory>
could even test the same cases of the enum with different combinations of the wires as well, its being used in my next state logic block
maikmerten has quit [Remote host closed the connection]
<sxpert>
good luck with that ;)
<chaseemory>
hehe I like trying to new things to see how they work :D
<sxpert>
yeah
<sxpert>
sometimes, they fail spectacularly for no reason
<chaseemory>
dont I know it, now that Ive gotten into ASIC toolchains in school vs just FPGA ones till now, they can go belly up quick and in strange ways