<whitequark>
my understanding is that the fine pitch masks cost so much that the fewer of them you need the better
oeuf has quit [Read error: Connection reset by peer]
oeuf has joined ##openfpga
dj_pi has quit [Ping timeout: 248 seconds]
<sorear>
that’s my guess as well
<sorear>
consider also that a long thin trace would have awful RC delays
<whitequark>
indeed
<mithro>
I mean it makes a lot of sense and also makes sense why top metal only changes are cheaper too....
* zignig
reads the new boneless v3 code.
<whitequark>
note that it is only a prototype yet
<whitequark>
the general shape will be the same, the exact code not so much
<zignig>
whitequark: understood, the structure is very different to v2.
<zignig>
I have been working on a serial bootloader ( for the v2 core ) , that I will need to port once v3 has settled.
<azonenberg>
mithro: there's other reasons too
<azonenberg>
it also allows you to have two metal etch lines
<azonenberg>
one for fine pitch and one for coarse
<azonenberg>
you can run both in parallel with wafers at different steps of fab, but you can use older, less expensive hardware for the upper layers
<azonenberg>
or even move wafers to an older fab for the upper layers
<azonenberg>
some classified gov chips do exactly this, they outsource the std cells to e.g. TSMC because no US fabs can go that small, but in an obfuscated pattern so you can't infer much/anything about the chip's functionality
<azonenberg>
then they use a less fancy but trusted fab, say IBM, to do the upper layers
<sorear>
i wonder how "obfuscated pattern" compares to "standard gate array"
<sorear>
gate arrays (non-programmable, field- or otherwise) are apparently still a thing but not a market I have much visibility into
flea86 has joined ##openfpga
<mithro>
sorear: I think I have heard that called a "sea of gates"?
<sorear>
I've heard that
vonnieda has joined ##openfpga
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
rohitksingh_work has joined ##openfpga
_whitelogger has joined ##openfpga
OmniMancer has joined ##openfpga
gsi__ is now known as gsi_
craigjb has joined ##openfpga
craigjb_ has quit [Ping timeout: 246 seconds]
Maya-sama has joined ##openfpga
m4ssi has joined ##openfpga
emeb_mac has quit [Ping timeout: 245 seconds]
Maya-sama has quit [Ping timeout: 258 seconds]
<azonenberg>
my understanding is that there is actual research into cryptographic means of doing exactly this
<azonenberg>
basically figure out how to perturb a physical netlist to make it as hard as possible to figure out connectivity
<azonenberg>
while not hurting timing more than X amount
<sorear>
"logic encryption" is what usually gets studied and it's a harder problem where the adversary gets the complete netlist but not a small number of key bits that get fused later
Maya-sama has joined ##openfpga
Asu has joined ##openfpga
Maya-sama is now known as Miyu
Miyu has quit [Ping timeout: 244 seconds]
linzhi-sonia has joined ##openfpga
Miyu has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 258 seconds]
rohitksingh_work has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 245 seconds]
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 246 seconds]
Dolu has quit [Ping timeout: 244 seconds]
rohitksingh_wor1 has quit [Ping timeout: 245 seconds]
rohitksingh_work has joined ##openfpga
Dolu has joined ##openfpga
Bike has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 245 seconds]
rohitksingh_work has joined ##openfpga
cr1901_modern1 has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
cr1901_modern has quit [Ping timeout: 258 seconds]
OmniMancer has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
rohitksingh_ has joined ##openfpga
rohitksingh_ has quit [Client Quit]
rohitksingh has quit [Client Quit]
rohitksingh has joined ##openfpga
renze has quit [Ping timeout: 245 seconds]
renze has joined ##openfpga
rohitksingh has quit [Ping timeout: 272 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 258 seconds]
rohitksingh has joined ##openfpga
genii has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
emeb has joined ##openfpga
<emeb>
fun getting an ILI9341 color LCD working on a picorv32 in a up5k using the hard SPI core.
<Xark>
emeb: Neat. What kind of SPI clock speed can that use?
<emeb>
Xark: the SPI IP core really needs at least a 1/3 baud rate divide from whatever the system clock is. I'm running it from 24MHz right now, so 8MHz sclk I guess. Plus, with the wishbone overhead and the status polling it slows down a bit more.
<Xark>
emeb: Nice. IIRC the datasheep on those displays says 20Mhz (but that seems to be conservative).
<emeb>
A full screen refresh on this 320x240 LCD is not instantaneous - you can see it wipe, but it's not awful. I suspect that if the SPI core were clocked at 48MHz it would be nicer, but the picorv32 doesn't really want to run faster than 24MHz on the up5k with the conservative timing that nextpnr uses.
<Xark>
emeb: With 8Mhz the max speed is not super impressive (but decent). I did a fair bit of work to see how fast these could go on 16Mhz AVR (8Mhz SPI clock). However, a lot of "compute delays" between SPI data on AVR (a buffer helps a lot). Here is my AVR "speedy LCD" project (with benchmarks at the bottom): https://hackaday.io/project/6038-pdqgfx-optimzed-avr-lcd-graphics/details
m4ssi has quit [Remote host closed the connection]
<emeb>
Cool. It's fun trying to get the most out of these constrained systems.
<emeb>
Fun part of this is that I'm using both SPI cores - one for the flash memory and the other for the LCD. Next thing to try is copying images from flash to LCD.
<Xark>
emeb: I got my 6502 firmware back operational (with color+gplyh output/scroll). However, now I notice top scan line isn't "right" (like line 0 shows data from middle of the screen - my fixes aren't quite perfect).
<emeb>
Hmm... Well, debugging hardware is part of the fun. I need to study that design and think about how I'd fix the issue you discovered.
<tnt>
ZipCPU: Having it work on real hw rather than simulation is the trick though because you have in/out delays to/from outside of the FPGA that are in the order of magnitude of the clock period ...
<tnt>
so unless you account for that, proving it in sim doesn't mean much.
<ZipCPU>
Hmmm ....
<ZipCPU>
tnt: The difficult part of the slave core you propose is that ... it's so hardware dependent
<ZipCPU>
I'd rather create something that was a bit more hardware independent ... pure Verilog if you will
<tnt>
ZipCPU: sure. I just couldn't come up with one that worked reliably at high SPI frequency.
<ZipCPU>
The reality is that I'd love to place this on an iCE40 as well, so ... there is that in common
<ZipCPU>
How fast was the SPI frequency you were working with?
<tnt>
~ 50 MHz
<ZipCPU>
HX8k?
<tnt>
UP5k
<ZipCPU>
50MHz should be reasonable
<ZipCPU>
Indeed, you should be able to run at up to 100MHz SPI clock
<tnt>
Yeah, the frequency isn't so much the problem. The two reasons I had to resort to hw dependent things are :
<whitequark>
ZipCPU: this is why nMigen has a platform layer providing an abstraction over DDR primitives that is the same on every family.
<whitequark>
pure Verilog just isn't enough for things like that
<tnt>
(1) next pnr doesn't support delay constraint across clock domain and I needed to limit the possible skew between bits during CDC.
<ZipCPU>
Technically, DDR from Verilog works just fine. Practically, its abysmal.
<tnt>
(2) Couldn't use the IOB register (for various reason), so to get deterministick Clock-to-out and setup-hold times vs spi-clk pad, I need to manually lock where those signals go to / come from.
<tnt>
Which again, you can only do by manual instanciations of low level primitives.
<ZipCPU>
tnt: (1) Why? Why not just guarantee that there will be enough skew by holding the source constant while the valid goes through the synchronizer?
<whitequark>
ZipCPU: the nMigen platform layer provides more guarantees about DDR than you can do in pure Verilog
<ZipCPU>
(2) ... sadly, I understand this one. I keep "finding" bugs in code sent to me--things that work in version XYZ or Yosys but not xyz, and it usually turns out to be that clock-to-output issue
<whitequark>
specifically, it synchronizes both samples to the next clk posedge
<tnt>
ZipCPU: if I want to support system clock of a picrorv 32 at 12 MHz with a SPI at 60 MHz (untested yet, but that was the design target), I need to pass 1 data almost every 12 MHz clock ...
<whitequark>
(by instantiating the appropriately configured primitive)
<ZipCPU>
whitequark: I believe it, and I can understand why you do it as well. Tell, me though, can you do this across multiple hardware architectures (yet)?
<whitequark>
ZipCPU: yes. this is currently done across ECP5, iCE40, Xilinx S7, Xilinx Spartan6, and there is a prototype for MachXO2 (not upstream yet)
<cr1901_modern>
Spartan3 will also prob follow this afternoon
* cr1901_modern
waves
<ZipCPU>
tnt: All of my clock passing primitives are failing in formal for SPI speeds > 2x my system clock. I just can't seem to get the data through the 2ff synchronizers fast enough
<ZipCPU>
whitequark: Forgive me for saying, but that's awesome!
<whitequark>
ZipCPU: I have spent a lot of time looking at various FPGA primitives and found the configuration that is either natively supported, or can be very easily and reliably provided, on pretty much every interesting architecture.
<cr1901_modern>
whitequark: I have an overwhelming urge to actually finish something today. So why not choose the task w/ that seems like the least amount of work and watch it gloriously blow up in my face :P
<whitequark>
you *do* have to consider pipelining in the input buffer
<cr1901_modern>
(there will be a PR hopefully tonight)
<whitequark>
i.e. both posedge and negedge sample are re-registered, delaying them by 1 clock.
<whitequark>
but that is a small price to pay for I/O that is (a) portable, (b) is entirely in a single clock domain
<ZipCPU>
The input buffer ... that's one thing I'm not examining at this point
<tnt>
whitequark: I don't really see why you couldn't write a HAL layer in verilog ... (my last company had one in VHDL that abstracted BRAMS / Multipliers / ... to allow instanciation and napping to different vendor/architecture depending on the compile time option).
<whitequark>
tnt: you could, absolutely
<whitequark>
but you can't *rely* on it if you're shipping Verilog code
<whitequark>
whereas nMigen guarantees that you can use that, and also gives you a specific interface to write code against
<tnt>
Sure, you'd need to ship it with the code ... (or as a library/dependency whatever). And I agress it's very nice than nmigen comes with "batteries included" with things like this HAL or FIFOs or memories or that kind of stuff "ready out of the box".
<whitequark>
ZipCPU: here by "input buffer" I mean something more abstract than the physical buffer on the FPGA.
<ZipCPU>
Ok, then ... I'm confused
<ZipCPU>
That's what I had thought you were talking about
<whitequark>
let me try to explain
* ZipCPU
remembers Prince Bride, "No, there is too much. Let me sum up." :D
<whitequark>
if you ask nMigen for a DDR I/O, it essentially gives you a bunch of wires (like an SV struct, maybe?) that follow a specific contract. for example, if you ask it for a DDR input, it gives you "clk", "i0" and "i1".
<ZipCPU>
... and it automatically maps it to a hardware abstraction layer, sort of like tnt was suggesting?
<whitequark>
the contract is that, provided that you drive "clk" from the same domain as your logic is in, on each "clk" posedge, "i1" contains the value at the previous negedge, and "i0" at the posedge before that (i.e. with 1 clock delay).
<whitequark>
yes. in practice, nMigen has a hardware abstraction layer it uses to implement that.
<whitequark>
but that should not matter very much if you are following its contract.
<tnt>
I might have lost a step here, but why are DDR primitives needed at all here ?
<whitequark>
on twitter, ZipCPU was talking about MOSI and MISO changing on different clock edges
<whitequark>
SCK edges*
<whitequark>
of course nMigen provides SDR primitives as well
<ZipCPU>
Ooohhh, I had missed the connection ... that makes a lot more sense now, thanks!
<ZipCPU>
The problem, though, is that ... I'm not driving SCK. This is a slave SPI port
<ZipCPU>
SCK is being driven externally
<whitequark>
I see. I would use a similar approach here as well.
Asu has quit [Remote host closed the connection]
<whitequark>
I would use a DDR primitive configured such that the input data is valid on SCK posedge, and have a domain clocked by SCK. then any desirable CDC primitive transferring data to the system domain.
<tnt>
sure, but (1) you're outputting on one and capturing on the other so that's not really DDR. (2) in the IO timing analysis I did, when you account for the skew between clock path and data path, you're better off capturing MOSI on the rising edge as well (the data capture valid window will be somewhere between falling and rising edge)
<ZipCPU>
^ +1
OmniMancer has joined ##openfpga
<ZipCPU>
Where I could see DDR primitives becoming valuable here is if you took all of the incoming SCK signals and sent them through a DDR primitive
<ZipCPU>
... that is, with the system clock controlling the DDR primitive
<ZipCPU>
That would spare you a cycle of clock synchronization time, would it not?
<whitequark>
you could oversample too.
<ZipCPU>
That's essentially what I'm describing, only using the DDR primitive to do it
<whitequark>
(side note: one thing I want to provide in nMigen is an abstraction for low-speed SERDES... like Xilinx ISERDES and Lattice IDDRX2)
<whitequark>
ZipCPU: yeah, I meant that you're describing oversampling :)
Asu has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
genii has quit [Remote host closed the connection]
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
Asu has quit [Client Quit]
Richard_Simmons2 has quit [Ping timeout: 252 seconds]
Richard_Simmons2 has joined ##openfpga
Richard_Simmons2 has quit [Remote host closed the connection]
Richard_Simmons2 has joined ##openfpga
sgstair has quit [Read error: Connection reset by peer]
sgstair has joined ##openfpga
Zorix has quit [Read error: Connection reset by peer]
<Xark>
emeb_mac: Hi. I was thinking I found another minor issue with PS/2 ASCII decoding with "|" and "}" keys, but I found out that OSI messed up the ASCII character order in the font (D'oh). :)
<Xark>
emeb_mac: I am tempted to "fix" the font - since "OSI compatiblity" is mostly gone with larger screen (and other differences).
* Xark
does note that OSI didn't even have keys for those characters (in their defense). Few C programmers on OSI back then... :)
Zorix has joined ##openfpga
<Xark>
emeb_mac: I also found that "--timing-allow-fail" is handy for your "false path" timing error (since typing make twice gets old).
<emeb_mac>
Xark: That's weird - hadn't noticed it
<emeb_mac>
but then those characters don't often come up in Basic
<emeb_mac>
also, thanks for the --timing... suggestion. Will add that to the make