<tpb>
Title: Turn restriction routing - Wikipedia (at en.wikipedia.org)
<corecode>
can you explain how it can deadlock?
leviathanch has joined #yosys
<emeb_mac>
hah, fun - got a simple little 6502-based system running in u4k (my breakout) and hx1k (icestick). fun part was setting up the makefile to include building the ROM contents from 6502 assembly code.
gsi_ has joined #yosys
gsi__ has quit [Ping timeout: 245 seconds]
<promach_>
corecode : spidergon with all master nodes will have the possibility of cyclic packet transaction
<promach_>
cyclic packet flow will lead to deadlock
<promach_>
this is all the fault with spidergon deterministic routing algorithm
<promach_>
corecode
<emeb_mac>
general question: when building a design in yosys/nextpnr, is there a way to just change the EBR contents w/o rebuilding everything from scratch?
proteusguy has quit [Ping timeout: 246 seconds]
shuggsy has joined #yosys
shuggsy has quit [Client Quit]
shuggsy has joined #yosys
shuggsy has quit [Client Quit]
shuggsy has joined #yosys
pie__ has joined #yosys
shuggsy has quit [Client Quit]
shuggsy has joined #yosys
shuggsy has quit [Client Quit]
AlexDaniel has quit [Ping timeout: 268 seconds]
pie___ has quit [Ping timeout: 268 seconds]
rohitksingh has joined #yosys
_whitelogger has joined #yosys
_whitelogger has joined #yosys
leviathanch has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 250 seconds]
emeb_mac has quit [Ping timeout: 255 seconds]
proteusguy has joined #yosys
proteusguy has quit [Ping timeout: 246 seconds]
proteusguy has joined #yosys
leviathanch has joined #yosys
<corecode>
promach_: why deadlock?
<promach_>
corecore : because packet went into cyclic path
<corecode>
a single packet?
<daveshah>
emeb_mac: there is icebram
<daveshah>
It should work with vendor tools too
<promach_>
corecode : no, all nodes issue packet to the next neighbouring node
<promach_>
do you get it ?
<corecode>
why is that a deadlock
<promach_>
corecode : because deadlock is something that locks everything down
<promach_>
imagine all nodes send at the same time instant
<promach_>
corecode
<promach_>
with turn-restricion, then deadlock will not happen
<promach_>
corecode : but spidergon is using shortest path routing algorithm which does not consider the deadlock problem
<corecode>
can you explain the deadlock
<corecode>
you're saying that it leads to deadlock, but i don't see how
<tnt>
I think figuring out why 'xxx is "unused"' is where I spend most of my time when synthesizing stuff for the first time.
<corecode>
so we start out by having all nodes send a packet to their neighbor
<promach_>
corecode : es
<promach_>
yes
<promach_>
let say in a restaurant, we have a cicle of tables
<corecode>
nono
<promach_>
and we have 8 tables
<corecode>
no analogy
<promach_>
we have 8 couples
<corecode>
i can't work with analogies
<corecode>
my brain can't translate
<promach_>
all of them are sitting in the table
<promach_>
all nodes are chained in a cicular manner
<corecode>
yes
<promach_>
node 0 sends packet to node 1
<corecode>
yes
<promach_>
node 1 sends packet to node 2
<corecode>
yes
<promach_>
node 2 sends packet to node 3
<promach_>
node 3 sends packet to node 4
<promach_>
node 4 sends packet to node 5
<promach_>
node 5 sends packet to node 6
<promach_>
node 6 sends packet to node 7
<corecode>
yes
<promach_>
node 7 sends packet to node 0
<corecode>
yes
<promach_>
now do you see deadlock
<corecode>
no
<promach_>
moving packet across from one node to the another node requires time latency
<corecode>
yes
<promach_>
this is physical world, remember
<promach_>
I mean hardware
<promach_>
wiring time
<corecode>
so it takes, say, 32 clock cycles to transmit a packet
<promach_>
let say each packet transfer requires 1 clock cycle
<promach_>
node 0 cannot send packet to node 1 if node 1 does not have buffer space
<corecode>
okay
<corecode>
why doesn't it have the buffer space?
<promach_>
node 1 cannot send packet to node 2 if node 2 does not have buffer space
<promach_>
because it is occupied
<promach_>
does not have enough buffer space
<corecode>
how is it occupied
<promach_>
this has to do with all the packet routing
<corecode>
okay
<corecode>
please explain
<promach_>
all nodes are initially full
<corecode>
why?
<promach_>
because it is full
<corecode>
what's in there
<promach_>
filled from packets routed during previous timestep
<corecode>
okay
<promach_>
do you get the meaning of deadlock now ?
<tpb>
Title: GitHub - enjoy-digital/versa_ecp5: Versa ECP5 SoC based on LiteX (at github.com)
<somlo>
so litedram proper and versa_ecp5, then -- cool!
<somlo>
I need a starting point to rip out just the dram controller and the C program used to initialize it, so I can graft it onto the rocket chip based SoC :)
Laksen has joined #yosys
<somlo>
so Lattice have decided to send me a proper 5g versa board, and they're letting me keep the franken-version with a non-5g FPGA -- might be worth something as a weird collectible one day in the future (or not) :)
flaviusb has quit [Quit: Leaving.]
rohitksingh has joined #yosys
flaviusb has joined #yosys
rohitksingh has quit [Ping timeout: 255 seconds]
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 255 seconds]
rohitksingh has joined #yosys
lutsabound has joined #yosys
rohitksingh has quit [Ping timeout: 250 seconds]
<MoeIcenowy>
somlo: board with wrong chip?
<MoeIcenowy>
collectible ;-)
svenn2 has joined #yosys
svenn has quit [Read error: Connection reset by peer]
maikmerten has quit [Quit: Verlassend]
emeb_mac has joined #yosys
leviathanch has quit [Remote host closed the connection]
knielsen has quit [Ping timeout: 240 seconds]
knielsen has joined #yosys
rohitksingh has joined #yosys
promach_ has quit [Ping timeout: 255 seconds]
rohitksingh has quit [Remote host closed the connection]
<MoeIcenowy>
daveshah: btw is DFF initialization implemented in ECP5 Yosys?
<MoeIcenowy>
daveshah: in fact I think I have done the same thing for Anlogic
<MoeIcenowy>
via "dffinit -strinit SET RESET -ff AL_MAP_SEQ q REGSET -noreinit"
<MoeIcenowy>
do you think this scheme familiar? ;-)
<daveshah>
yeah, this pass also has to deal with conflicts between sync set/reset and initialisation (by blowing the sync set/reset back to logic in a conflict)
<MoeIcenowy>
oh maybe I should drop my code and port ecp5_ffinit to anlogic
develonepi3 has quit [Remote host closed the connection]
<cr1901_modern>
Note that adapting this to modern FPGAs... well, it stinks. 65816 is a 5V CMOS CPU, so TTL levels don't work for it and associated peripherals
<cr1901_modern>
on the other end of the MMU you'll need level shifters for 5V CMOS peripherals that natively speak to 65816
<emeb_mac>
I've been lurking over on that Commander 16 project on FB where they're trying to design a 65816 retrocomputer.
<emeb_mac>
it's kind of hilarious/sad all the conflict they're having over the use of FPGAs
<sorear>
cute
<cr1901_modern>
well, maybe you don't need all that much converted back to 5V on the I/O side of the MMU... a greenpak powered at 5V could do dual addr decoding and level shifting
<tnt>
emeb_mac: is that the 8bit guy project ?
<cr1901_modern>
He rubs me the wrong way
<cr1901_modern>
but I could just be jealous of his success
<cr1901_modern>
(and there are some... flaws w/ his "how 8-bit graphics work" that my NES hacker friends like to point out :P)
<cr1901_modern>
"how 8-bit graphics work" video*
<tnt>
oh yeah, it's not always the most technically accurate. For that gotta watch the 'ultimate talks' series from ccc :p
<tnt>
we need a 'ultimate ice40 talk' with all the tech details of all the blocks the routing and all that stuff :)
<emeb_mac>
tnt: yes
<emeb_mac>
it's a neat idea, but their self-imposed limits seem kind of shortsighted, and I suspect they'll have a hard time hitting that $50 price point goal without losing their shirts.
<tnt>
I didn't read anything on the fb group, but esden and I actually sent him a proposal for an ice40 gpu (and matching hdmi driver and bus interface), but he turned it down, so didn't really follow after that.
<cr1901_modern>
c256 foenix looks interesting
<cr1901_modern>
it's sorta what I would do if I were making my own 65816 computer
<cr1901_modern>
I would use FPGAs for: address decoding, MMU, i2c bus, uart, and spi bus. The UART is because the current ACIA silicon by WDC is very broken
<esden>
I had a few back and forth with him when he turned us down. Regarding pricing. He insisted it was fine to use the xilinx chip for video, because someoen told him he will be able to source the chips for $5. I ended up wishing him good luck, and if he is interested he knows how to reach us. :)
<esden>
And honestly. I am even more curious if he will be able to source the 65C2xxx chip for a reasonable price. Without good chip distributor contacts and large production quantities, these things are not that simple to get.
<cr1901_modern>
65c2xx is the microcontroller variant IIRC
<cr1901_modern>
it's an interesting beast
<esden>
I don't doubt it is interesting. ;)
<cr1901_modern>
esden: I like WDC a lot- they are receptive to hobbyists inquiries. But it's quite a mystery to me where their actual business comes from.
<cr1901_modern>
b/c it ain't from Joe nobody like me
<daveshah>
Plenty of still built old designs I'm sure
<daveshah>
Particularly applications which are certified and expensive to change
<cr1901_modern>
(the VP of Business and Development David Cramer helped me out personally over email when I had trouble buying some 65816s a few years ago from a vendor.)
<cr1901_modern>
WDC is fabless; they used Sanyo up until I want to say 2015; now they use TSMC
<esden>
Yeah the amount of old chips in industrial applications is astonishing. I bet in certified systems there is even more of that.
<cr1901_modern>
(Tbh, I thought for the longest time Sanyo was a kitchen appliance manufacturer)
<emeb_mac>
WDC is about 5 miles from where I live.
<cr1901_modern>
Oh that's cool
<cr1901_modern>
>In 2010, Sanyo sold its semiconductor operations to ON Semiconductor. [16] Oops
<sorear>
Are they still using the old masks for anything or is the Verilog version the only one now
<emeb_mac>
but I agree with esden that they'll have trouble with pricing, not just on the CPU & FPGA too.
Laksen has quit [Quit: Leaving]
<sorear>
My general philosophy on this sort of system stuff is you want to balance complexity between components, and using a ca. 10 kGE core like 65816 with >>1Mbit of memory is unbalanced and silly
<emeb_mac>
heh - the village idiot driving a lamborghini :)
<esden>
I also heard him say, "I am not concerned about the hardware that much, software is much more important at the moment." although I partly agree. He did mention the aggressive $60 retail target, and I think they are being overly optimistic. To emeb_mac's point, even if the main components seem to be "gettable" in the right price bracket, there is a lot of supporting components that will add up.
<cr1901_modern>
sorear: I dunno... in principle 65816 could run a full fledged *nix if you actually gave it a full 16MB of RAM. The main problem is that functions have to be limited to 64kB boundaries (or a linker relaxation pass would have to break a function that straddled the boundary into two chunks).
<sorear>
who are we talking about?
<cr1901_modern>
I think that would be cool
<cr1901_modern>
sorear: 8-bit guy
<sorear>
i,i Sanrio semiconductors
<cr1901_modern>
._.
<emeb_mac>
Those Spartan 6 LX9 chips are listed @ ~$18 / qty180. You might be able to get them cheaper if you cozy up to the Xilinx reps and get the "friend & family" pricing. This project *might* be high enough profile that they'd buy in. Might.
<daveshah>
Unlikely, with my experience of Xilinx reps in the UK a few years ago at least
loxodes has joined #yosys
<daveshah>
The best price we got was higher per unit than digikey
<daveshah>
In qty 1000
<emeb_mac>
A guy I know managed to talk Xilinx down to about $10 for an SDR project he was going to do, but there were a lot of strings attached.
<emeb_mac>
(on the S6 LX9)
<daveshah>
I suspect in this case they are relying on cheapo "secondary" distributors
<daveshah>
Not a risk I'd take for something like this, but each to their own
<emeb_mac>
ever popular Chinese gray market
<emeb_mac>
ice40 HX would definitely be a better bet for something that doesn't need lots of DSP cores.
<esden>
Yeah, I can confirm that it really depends on how cozy you are with the "right people" from the chip vendor. And developing those relationships takes a lot of time, even if you have a "high profile" project. But who knows he might know someone, he does have a lot of tech people watching his channel.
<cr1901_modern>
I really can't watch many retro channels on YT. I just get sad that I either A. missed my chance to get a piece of the retro pie, and/or B. don't have the right personality to have pulled off being a popular retro enthusiast lol
<cr1901_modern>
That market is very well saturated now
<esden>
I try to tell myself that I do not have space or time for it anyways. So I enjoy the fruits of the other people’s labor here. I have enough things to play with... ;) but sometimes I have similar feelings cr1901_modern
<cr1901_modern>
esden: The first step towards fixing a problem is admitting it exists. Well, I'm not really about the fix these jealous feelings tho LOL
<cr1901_modern>
If someone wants to dunk on 8-bit guy, and I know their credentials, I'm prob gonna listen. And wish it was me doing said videos and sipho- err making money off ppl's nostalgia instead
<cr1901_modern>
I mean shit, of course I'd love to be able to talk about/make hardware for obsolete machines and not have to worry about other work XD
<daveshah>
Get a job in the railway industry then :P
<daveshah>
Or military or marine
<esden>
Or aircraft...
<cr1901_modern>
Hmmm, well I do like trains (although foamers ensure I'll never talk about that out loud)
<esden>
My PnP is the biggest retro project that I have... and I would prefer if it was not retro to be fair... on the other hand it is probably easier to maintain without a support contract. ;D
<cr1901_modern>
PnP?
<esden>
Pick and Place machine
<cr1901_modern>
You're making an ISA Plug-n-Pray FPGA core?
<cr1901_modern>
ahhhh
<cr1901_modern>
yea I don't have the spare money for that
<esden>
well... it is not a toy in my case. I wish it was just that.
<esden>
Ahh the utopia where one can just work on interesting shit without worrying about materialism. :/
<cr1901_modern>
Hmmm fair point. I wasn't thinking of using it as a toy, but to make prototyping during contracts easier
<cr1901_modern>
since I'm not a wonderful manual pick-n-place machine
chaseemory has joined #yosys
<cr1901_modern>
esden: Was the 3-bit HDMI icebreaker PMOD meant to be a prototype?
<cr1901_modern>
contrast to the 16-pin PMOD
<cr1901_modern>
or was there supposed to be an 8-pin 3-bit and 16-pin "whatever"-bit verson?
<esden>
For less boards than 10 it is usually faster to place by hand than setup a PnP.
<esden>
The 3bit one was a prototype based on Kevin's design. The 4bit version is the successor to it, based on tnt's suggestion. This is what I will be making and selling in the store. The 12bit version is part of the crowd funding campaign, and this is what "people" will be getting.
<cr1901_modern>
ahhh
<cr1901_modern>
(who is Kevin, btw?)
<cr1901_modern>
anyways I have the 3-bit version which is fine for my needs. Making the 4-bit at home might be fun
<esden>
There is a new version of the 4 and 12 bit coming, with more jumpers, again a good suggestion from tnt. ;)
tpb has quit [Remote host closed the connection]
<esden>
cr1901_modern: making a 4 bit version is very easy, you just need to lift 3 legs on the chip and wire them up to the NC pin on the PMOD.
tpb has joined #yosys
<esden>
tnt: has a photo of his bodge.
<cr1901_modern>
do not underestimate my ability to screw this up
<esden>
what you break you can fix ;)
<cr1901_modern>
how do I lift just 3 legs off the chip?
<cr1901_modern>
esden: ENOEXACTO for broken traces