<cr1901_modern>
ZipCPU: I wasn't aware clifford responded. My Internet was acting up this morning (2-6AM)
<ZipCPU>
He hadn't. We chatted about it. ;)
<cr1901_modern>
ZipCPU: I want to prove that both modules produce the same outputs for arbitrary inputs
<ZipCPU>
It's not quite a generic memory, now, is it? Or should I say ... it's too generic?
<ZipCPU>
Maybe that's what's making this difficult.
<cr1901_modern>
It's a dual-port memory w/ write-first semantics. I don't see what's so complicated about that
<ZipCPU>
Is that all it is?
<ZipCPU>
The `ifdef's are making triport.v harder to figure out.
<cr1901_modern>
Yes. Both modules are _supposed_ to be dual-port memories w/ write-first semantics, with a stall signal to hold the previous value
<cr1901_modern>
Oh, I should probably remove those at this point. The idea was to mimic a 3-port register file, but I gated those out
<ZipCPU>
Let's try this, looking at triport.v, should TRIPORT be defined or not?
<cr1901_modern>
No
<cr1901_modern>
Not for this test
<cr1901_modern>
TRIPORT == "Add a second read port"
<ZipCPU>
How about WRITE_FIRST? Should that be defined? Can I get rid of that if-def?
<cr1901_modern>
Yes that should be defined
<cr1901_modern>
All you need is -DWRITE_FIRST
<ZipCPU>
Ok, let me define that manually for now ...
<ZipCPU>
Should READ_FIRST be defined as well ever? Or can I remove that from the design?
<cr1901_modern>
Remove it for now. Feel free to send a pull if you wish
<ZipCPU>
And those spaces ... you must be an emacs user ...
<cr1901_modern>
I'm quite preoccupied with something unexpected tonight, so I can't really work on this
<cr1901_modern>
No, Atom
<ZipCPU>
(You sure you still want that pull ??)
<ZipCPU>
That's ok.
<cr1901_modern>
I'll modify it myself later
<cr1901_modern>
I don't like any command line editor really, but I can tolerate nvi and cscope/ctags if I absolutely have to
<ZipCPU>
;)
vinny has quit [Quit: Page closed]
<ZipCPU>
Any reason why you are setting a wire on the positive edge of a clock?
<cr1901_modern>
Probably by mistake, if that counts as a reason. But forget about it tonight
<cr1901_modern>
(please :3)
<ZipCPU>
All right, I'll be quiet.
<cr1901_modern>
It's not that, it's just I think my NAS is failing, and need to decide what to do (I'd really rather not sink the cost of a new one right now)
<ZipCPU>
You know that the yosys channel is recorded, right?
<cr1901_modern>
Yes, I'm the one who asked whitequark to log it
<cr1901_modern>
I'm simply saying I cannot dedicate the attention you deserve right now, esp considering you're taking time out of _your_ day to help me
<ZipCPU>
Ahh, I can recognize this now, this is CPU register "memory".
<cr1901_modern>
Yes
<cr1901_modern>
triport_explicit is a _very_ specific reimplementation that requires a synthesizer to infer less "glue logic" to create a write-first transparent RAM.
<cr1901_modern>
But the glue code yosys generates in triport.v is different from the explicit version, and I'm worried they aren't actually equivalent
vinny has joined #yosys
sklv has quit [Ping timeout: 272 seconds]
sklv has joined #yosys
maroni has quit [Ping timeout: 240 seconds]
<ZipCPU>
So ... triport is the original and triport_explicit is the "updated"?
<cr1901_modern>
triport is indeed the original, triport_explicit is "I ripped some code out of lm32 to test something"
<ZipCPU>
I've torn these two files apart quite a bit now.
<ZipCPU>
I think I'm done with triport.v. It's the same code, but you might not recognize it. ;)
<ZipCPU>
Still working on triport_explicit ...
<ZipCPU>
Although .... since I took out the dual-port read functionality, you might argue it's no longer a "triport"
<cr1901_modern>
ZipCPU: I wouldn't touch triport_explicit. I don't know for sure that I ripped it out of lm32 correctly
<cr1901_modern>
ZipCPU: The naming is unfortunate, but it's here to stay
<ZipCPU>
Well ... it's a little too late to not touch the explicit one. I mean, I could go back to github, but ...
<ZipCPU>
I want to get this down to the essence, to the point where I can then tell if yosys is doing the right thing or not.
<cr1901_modern>
It would be easier if I could just select that part of the design and have yosys write out the selected nets, but hindsight is 20/20
<ZipCPU>
I suppose you still could
<ZipCPU>
Yosys does have a write_verilog capability.
<ZipCPU>
It might still make sense to do that
<cr1901_modern>
I haven't yet b/c well the "select" command of yosys is a very complicated command and ENOENERGY
<ZipCPU>
Yeah, ahm ... I'm starting to become convinced that those are not the same circuit.
<ZipCPU>
I'm also getting a different message from yosys: "ERROR: Can't match gold port rd_data_gold to a gate port"
<cr1901_modern>
great...
<ZipCPU>
... which is actually what you might expect.
<ZipCPU>
Let me post what I've done into a github gist ...
gnufan has quit [Quit: Leaving.]
<cr1901_modern>
All I wanted to do was figure out whether yosys was instantiating a register file correctly. But if the circuits are indeed different I want to know why yosys isn't generating
<cr1901_modern>
the same circuitry as the explicit version.
<cr1901_modern>
At the very least yosys is smart enough to add the logic for write-first to work properly
<ZipCPU>
Phoey, still got "reg_rd_addr" as a wire instead of a reg ...
<cr1901_modern>
But the explicit version contains extra logic to hold the previous data output in case of a stall in the decode stage.
<cr1901_modern>
It's not possible to prevent a new address from being registered during the stall signal in lm32
<cr1901_modern>
during the _cycle_ when the stall_decode_stage signal is asserted.*
<ZipCPU>
The reg_rd_addr I was referencing was in triport.v, not triport_explicit.v
<cr1901_modern>
Oh I know. I'm simply explaining in detail what I'm trying to do while it's fresh in my head
pie_ has joined #yosys
pie__ has quit [Remote host closed the connection]
<ZipCPU>
You know, after boiling that down to its essentials ... it's not really all that different from the ZipCPU's register accessing.
<ZipCPU>
;)
<ZipCPU>
Except ... four of the ZipCPU registers aren't kept in the register file ...
swick has quit [Ping timeout: 276 seconds]
swick has joined #yosys
<cr1901_modern>
ZipCPU: Definitely looks much nicer
<ZipCPU>
;)
<sorear>
[vague off-topic curiousity: have you thought much about how linux interrupts will work? AFAIK linux assumes it's possible to enable interrupts in the kernel, which might be possible by running the kernel in "user" mode with the MMU off]
<ZipCPU>
sorear: Easy, simple answer: No.
<ZipCPU>
Never thought about it.
<sorear>
[with CONFIG_PREEMPT off you may be able to get away with no interrupts except in the idle thread]
<ZipCPU>
sorear: Sorry, I just don't have the background in the internal details of Linux to really comment.
<sorear>
sure
<sorear>
i thought you had already started the port, since you seem not to have, ignore this
<sorear>
doesn't affect me either way
<cr1901_modern>
After namespaces, cgroups, and That Init System took hold, I kinda lost confidence that I could understand Linux internals. Then I lost interest.
<ravenexp>
just wait till kdbus is merged
<cr1901_modern>
William's Law of Complexity: Let "a" be "the probability of an abstraction leak for all abstraction layers and interconnected components in a design."
<cr1901_modern>
Let "b" be "the time spent debugging/comprehending an abstraction leak when a layer or interconnect fails".
<cr1901_modern>
There exists a universal constant "c", satisified by a*b
philtor has quit [Ping timeout: 268 seconds]
sklv has quit [Ping timeout: 272 seconds]
philtor has joined #yosys
sklv has joined #yosys
brandonz has quit [Quit: WeeChat 2.0]
captain_morgan has quit [Remote host closed the connection]
captain_morgan has joined #yosys
m_w has quit [Ping timeout: 276 seconds]
pie_ has quit [Ping timeout: 260 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined #yosys
proteus-guy has quit [Remote host closed the connection]
sklv1 has joined #yosys
sklv has quit [Ping timeout: 272 seconds]
brandonz has joined #yosys
captain_morgan has quit [Remote host closed the connection]
captain_morgan has joined #yosys
gnufan has joined #yosys
vinny has quit [Quit: Page closed]
nrossi has joined #yosys
proteus-guy has joined #yosys
ar3itrary has quit [Remote host closed the connection]
dys has quit [Ping timeout: 265 seconds]
m_w has joined #yosys
m_w has quit [Ping timeout: 268 seconds]
dys has joined #yosys
eduardo_ has joined #yosys
MrBusiness3 has quit [Ping timeout: 265 seconds]
MrBusiness has joined #yosys
eduardo__ has quit [Ping timeout: 248 seconds]
proteus-guy has quit [Ping timeout: 255 seconds]
ar3itrary has joined #yosys
maroni has joined #yosys
digshadow has quit [Ping timeout: 265 seconds]
quigonjinn has joined #yosys
maroni has quit [Ping timeout: 240 seconds]
ar3itrary has quit [Remote host closed the connection]
ar3itrary has joined #yosys
ar3itrary has quit [Client Quit]
ar3itrary has joined #yosys
proteus-guy has joined #yosys
adj__ has quit [Read error: Connection reset by peer]
proteus-guy has quit [Ping timeout: 252 seconds]
adj__ has joined #yosys
maroni has joined #yosys
NotSpooky has joined #yosys
<NotSpooky>
Hello, I'm new to hardware design but already have experience on the software side. Do you have recommendations on which FPGA boards to use as starting point?
maroni has quit [Ping timeout: 240 seconds]
pie_ has joined #yosys
maroni has joined #yosys
<ZipCPU>
NotSpooky: Yes and no.
<ZipCPU>
My first recommendation would be a controversial one, but it would be to learn both Verilog and test benching before getting your first board.
<ZipCPU>
After that, it depends.
<ZipCPU>
Two of my favorite "first-boards" are the Basys3 and the Artix-7, and I have yet to try/prove the yosys design flow for those boards.
<NotSpooky>
All right, thank you very much.
<ZipCPU>
NotSpooky: Oooh, one other ...
<ZipCPU>
If you are $$ conscious, there are some cheaper boards as well.
<ZipCPU>
The Arrow Max1000 board is a cheaper board, as is the BlackICE FPGA board. Further, you can use the BlackICE board using yosys.
<NotSpooky>
Oh nice
<ZipCPU>
I think the Arrow was about $30 USD.
<ZipCPU>
Sorry, the MAX1000 from Arrow.
<ZipCPU>
It doesn't have nearly the "fun I/O" that the Basys3 or Arty have, but it still has some fun projects you can work on.
maroni has quit [Ping timeout: 240 seconds]
<NotSpooky>
I'd likely use FPGAs mostly for algorithms rather than crazy IO. But it'd nice if I can make an oscilloscope.
<NotSpooky>
But that is a secondary project
<NotSpooky>
By the way, is it possible to use Yosys with AWS F1 instances? They have Xilinx UltraScale Plus FPGAs
<sorear>
icestorm/symbiflow does not currently support UltraScale+
<shapr>
howdy sorear, how's life?
<sorear>
it may be possible to use yosys for some steps, but not end to end
<NotSpooky>
Oh ok. Thanks for the info.
<sorear>
https://twitter.com/oe1cxw/status/944300939145555971 suggests that it's on the roadmap; integrating with partial reconfiguration (since the F1 hardware protection disallows full reconfiguration) could pose its own problems
* sorear
wonders if acquiring test articles for the ultrascale+ will be a challenge; the F1 chip (XCVU9P-2) has a list price of $50,000
<shapr>
The Amazon F1 instances have UltraScale+ chips for rent
<shapr>
wouldn't that be the easier approach?
<qu1j0t3>
that's what NotSpooky asked about.
<shapr>
oh, ok
<shapr>
I should read the history
danieljabailey has quit [Read error: Connection reset by peer]
proteus-guy has joined #yosys
svenn has quit [Read error: Connection reset by peer]
svenn has joined #yosys
proteus-guy has quit [Ping timeout: 268 seconds]
proteus-guy has joined #yosys
proteus-guy has quit [Ping timeout: 248 seconds]
maroni has joined #yosys
maroni has quit [Ping timeout: 240 seconds]
maroni has joined #yosys
m_t has joined #yosys
m_t has quit [Quit: Leaving]
vinny has joined #yosys
digshadow has joined #yosys
maroni has quit [Quit: leaving]
nrossi has quit [Quit: Connection closed for inactivity]
dys has quit [Ping timeout: 246 seconds]
digshadow has quit [Ping timeout: 256 seconds]
NotSpooky_ has joined #yosys
NotSpooky has quit [Ping timeout: 260 seconds]
digshadow has joined #yosys
<thoughtpolice>
sorear: You can nab an UltraScale+ Zynq board for about $800 these days, at least...
<thoughtpolice>
Virtex-7 is closer to $6k for a devkit; Kintex ~$3k.
<thoughtpolice>
I don't know of any extant, low-price non-Xilinx kits for Kintex US+ or anything like that. The lowest one is Xilinx's board. But people are starting to put UltraScale+ Zynq into some stuff I think...
<thoughtpolice>
Technically if you throw up like $500 more that one could do PCIe too but a 1x lane only means it's pretty situational.
NotSpooky_ has joined #yosys
cr1901_modern1 has joined #yosys
cr1901_modern has quit [Ping timeout: 240 seconds]