scrts has quit [Remote host closed the connection]
scrts has joined ##openfpga
digshadow has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
digshadow has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
annuy has joined ##openfpga
annuy is now known as enriq
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<enriq>
sorry the ignorance :)
<enriq>
if I want to program a 16 bit counter on coolrunner ii, is it enough? I use the 16 macrocells?
DocScrutinizer05 has quit [Ping timeout: 258 seconds]
<azonenberg>
enriq: Yes, a counter will generally use one macrocell per bit
<azonenberg>
So a 2c32a could fit one 32-bit counter, or two 16-bit counters, or one 16-bit counter plus other logic
<enriq>
I want to make the control for a dual slope ADC. So the logic 1) select the input, 2) waits some fixed time, 3) switches the input to measure the Vref, 4) measure the time until crossing zero (detected with comparator externally)
<enriq>
I guess that for 16 bits it's not enough a coolrunner ii as the counter alone will eat the 16 macrocells
scrts has quit [Ping timeout: 240 seconds]
<enriq>
am I right azonenberg ?
<enriq>
but XC9572XL has 4 function blocks with 18 macrocells each, so should be adequate? just guessing...
DocScrutinizer05 has joined ##openfpga
scrts has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<azonenberg>
The xc2c32a has 32 macrocells
<azonenberg>
You have two function blocks with 16 mcells in each
<azonenberg>
So you'd use one FB for the counter and the other FB would be free for additional logic
<azonenberg>
Best option is to write the verilog for it, then see how big it turns out to be
<azonenberg>
And optimize if necessary
<enriq>
how do you know "how big" is it
<enriq>
there is this free tool, how is it called
<enriq>
icarus?
<azonenberg>
icarus is a simulator, not a synthesis tool
<azonenberg>
it's OK for testing your logic but won't tell you gate counts
<azonenberg>
You'd need to synthesize your logic to the target technology (coolrunner-ii) to get resource usage numbers
<azonenberg>
rqou: how mature is yosys support for coolrunner at this point?
<azonenberg>
enriq: i'd start with the xc9536xl since it's smaller
<azonenberg>
then read the datasheet, create a couple of simple designs that had various IO configurations and try to find the IO config bits
<azonenberg>
Probably decap the chip, etch down to a lower layer, look at the device floorplan to guess what bits might be located where
<azonenberg>
Try to find a programming spec, or RE a SVF to find what JED bits went to what actual jtag locations
<azonenberg>
since that would give a lot of hints about physical addressing
<azonenberg>
Lots of trial and error, twiddling bits in a bitfile to see what happens
<eduardo_>
"How do I reverse engineer an FPGA?" You start doing it because you dont know how hard it really is, go one step after the other, ask Clifford and azonenberg on the way and proceed until you are done.
<enriq>
heh
<enriq>
else delay my project until they finish these beautiful small tools :)
<azonenberg>
Lol
<azonenberg>
We're working on it :)
<enriq>
I can also hire someone to buy and install a windows machine with the official tools, but hobby does not pay
<enriq>
decap a chip a etch to watch at the microscope is beyond my knowledge
<azonenberg>
So if windows is the issue, that isnt a problem - ISE runs on linux
<azonenberg>
The big problem is that it's huge :p
<azonenberg>
18 GB for my copy of ISE 14.7
<enriq>
I hate that
<azonenberg>
Of this, 5 GB is EDK which you could delete
<azonenberg>
3GB is PlanAhead which you don't need for CPLDs
<azonenberg>
So that's down to 10 GB for the core of ISE
<enriq>
I'd rather do a 10x10cm board with lots of 74hc
<azonenberg>
Another 1-2 GB are for Virtex chips you won't need
<azonenberg>
So if you really wanted you could strip down an ISE installation quite a bit
<azonenberg>
Best option of course is to not use it :)
<azonenberg>
And lol
<enriq>
hahaha
<azonenberg>
If you want a well developed, largely production ready toolchain for a small device, check out my GreenPAK stuff
<azonenberg>
You might need more than one greenpak to fit your logic, depending on how big it is
<azonenberg>
but they're tiny (2x3 mm)
<azonenberg>
and cheap (around 0.50 USD per chip in low volume)
<azonenberg>
there's a handful of features i don't support but my toolchain is fairly stable and supports the majority of device functions at this time
<enriq>
looks nice, above my level for sure
<azonenberg>
why?
<azonenberg>
The official toolchain is fairly small (few hundred megs) and runs on win/linux/osx
<enriq>
I'm not informed enough in this field
<azonenberg>
mine is even smaller (under a hundred)
<azonenberg>
I think low tens
<enriq>
greenpak is a board based on what?
<azonenberg>
It's not a board
<azonenberg>
it's a chip
<azonenberg>
That i have a toolchain for
<enriq>
ahhh right
<azonenberg>
It's basically a CPLD with some analog components
<azonenberg>
a comparator, for example
<enriq>
a good comparator?
<azonenberg>
and two DACs
<azonenberg>
although you can really only use one at a time due to some quirks of how it's built
<azonenberg>
Define good :)
<azonenberg>
The DACs are i think only 8 bit though
<azonenberg>
But if you were OK with 8 bit precision you could probably fit your entire project into one of them
<enriq>
good is not like the one inside arduino
<azonenberg>
with no external components
<enriq>
no, I need 16 bits
<azonenberg>
You could still use it for the control loop
<azonenberg>
But you'd need an external dac
<azonenberg>
The chips only have 18 pins though, so you might have to combine two to control the whole dac
<enriq>
which control loop
<enriq>
for the psu?
<azonenberg>
you said something about a comparator and some logic to drive a dac
<azonenberg>
Alternatively, wait until we have more complete coolrunner support and do that
<azonenberg>
since it has some mixed signal stuff too (PGA, ADC, DACs, comparators)
<enriq>
looks nice
<azonenberg>
But yeah
<azonenberg>
And i have a fairly well developed toolchain for them using yosys + my own PAR
<azonenberg>
They're too small for a lot of stuff though
<enriq>
I was attacted to re-purpose one of those coolrunner boards sold to hack xboxes
<enriq>
but these chips are small enogh to use as many as needed
<azonenberg>
Yes, exactly
<azonenberg>
If you don't mind partitioning your design
<azonenberg>
they're not a bad choice
<azonenberg>
They are one-time programmable, which is a bit annoying
<azonenberg>
but they're cheap enough you can afford to go thorugh a few
<enriq>
ah
<azonenberg>
and they do have a SRAM programming mode for testing
<azonenberg>
But it's not in system capable
<azonenberg>
you have to do it on the devkit and as soon as the chip powers down it's blank again
<enriq>
it's a special chip for dev?
<azonenberg>
no, same chip
<azonenberg>
the OTP is copied to SRAM at boot
<azonenberg>
but you can also write directly to the RAM
<azonenberg>
The protocol is kind of clunky and uses all the pins so you can't do it in system
<enriq>
ah but you need a mcu
<azonenberg>
The greenpak5 generation is I2C programmable for SRAM (not sure if the OTP is in system programmable)
<azonenberg>
greenpak4 is not
<azonenberg>
As of now I have good support for the 46620 and 46621 (which is basically a 46620 that adds one more power pin and splits the IOs into two banks)
<azonenberg>
partial support for the smaller 46140
<azonenberg>
which is the whole GP4 generation
<azonenberg>
I have some GP5 samples to test, but have not had time to do any coding to add support for them yet
<enriq>
I'm kind of limited in choices as the market here is very small
<enriq>
(argentina)
<enriq>
I should use something cheap or readly available
m_w has quit [Quit: leaving]
<azonenberg>
Fuuun
enriq has quit [Ping timeout: 260 seconds]
massi has joined ##openfpga
awygle has joined ##openfpga
<awygle>
rqou: mram is faster and comparably-priced to fram but much higher power. generally seems targeted more at DRAM replacement and less at EEPROM replacement.
* awygle
has used both
digshadow has joined ##openfpga
<lain>
we used fram in panel meters for saving configuration state and such
<awygle>
both mram and fram have desirable properties re: radiation. good for space.
<lain>
it's nice because with sufficient capacitance you can dump state to fram on BOD before the whole thing goes kaput
<awygle>
lain: msp430fr#### are great for that. fram onboard and draw very little power
<lain>
oh neat
<lain>
TIL
teepee has quit [Ping timeout: 245 seconds]
teepee has joined ##openfpga
specing has joined ##openfpga
<rqou>
awygle: intended use case was NES/GB/whatever cartridge save data
<rqou>
so looks like nintendo was smart choosing FRAM for GBA :P
<awygle>
wait did they really? i had no idea
<rqou>
(also afaik mram didn't exist/wasn't commercialized yet at that point)
<rqou>
most (all?) non-bootleg GBA games that are marked as containing "SRAM" actually contain fujitsu FRAM
massi has quit [Ping timeout: 240 seconds]
<awygle>
sadly fram doesn't seem to scale well tho. iirc it's on like.. 130nm? haven't seen anybody go lower than that
<rqou>
so you shouldn't lose your save data if the internal battery dies
<rqou>
unlike on bootlegs, most of which used SRAM (even for games that weren't originally SRAM)
<rqou>
there is a generic save patcher tool for GBA games that matches on the code patterns in nintendo's sdk and patches games to save to sram instead
<awygle>
TIL. that's really cool. and also explains the "the battery has run dry" thing from pokemon RSE, which i didn't realize until just now makes no sense in an SRAM model
<rqou>
oh yeah, the other options other than FRAM are NOR flash (pokemon) and a serial eeprom that is interfaced using a hack
<awygle>
i like fram. i don't even know why, i just think it's cool.
<rqou>
where the clk line is hooked up to the data read strobe
massi has joined ##openfpga
<rqou>
and if you program the waitstates correctly and issue a dma request, it looks enough like an spi transaction
<rqou>
nintendo's custom mask rom also has a 4-bit gpio port that was used to attach random things like pokemon's rtc or warioware twisted's gyro
<rqou>
or boktai's solar sensor :P
<rqou>
some people replace pokemon r/b/y/g/s/c sram parts with fram so that they no longer have to suffer the pain of potentially losing their pokemon
<rqou>
unfortunately the particular pin-compatible fram part is pretty expensive
<awygle>
all fram parts are pretty expensive :(
<rqou>
you also need to somehow mod the circuit a little because you still need the battery for the RTC
<rqou>
on g/s/c at least
<awygle>
you know some very interesting things, rqou
<awygle>
i am going to sleep now tho. later folks
<rqou>
meh, these are all documented somewhere or other
massi has quit [Ping timeout: 276 seconds]
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
scrts has joined ##openfpga
massi has joined ##openfpga
massi_ has joined ##openfpga
massi has quit [Ping timeout: 255 seconds]
massi__ has joined ##openfpga
massi_ has quit [Ping timeout: 248 seconds]
teepee has quit [Ping timeout: 260 seconds]
teepee has joined ##openfpga
qu1j0t3 has quit [Ping timeout: 240 seconds]
massi__ has quit [Ping timeout: 258 seconds]
massi__ has joined ##openfpga
scrts has quit [Ping timeout: 255 seconds]
egg|work|egg has quit [Ping timeout: 260 seconds]
egg|work|egg has joined ##openfpga
awygle has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
qu1j0t3 has joined ##openfpga
coino has quit [Ping timeout: 246 seconds]
teepee has quit [Ping timeout: 255 seconds]
moho1 has joined ##openfpga
teepee has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
teepee has quit [Ping timeout: 245 seconds]
clifford has joined ##openfpga
teepee has joined ##openfpga
<clifford>
cr1901, azonenberg, "initial reg[3:0] foo = 4'ha;" delclares a LOCAL register foo within the initial block. It's completely bogus because the initial block is otherwise empty.
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
_whitelogger has joined ##openfpga
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
scrts has quit [Ping timeout: 276 seconds]
scrts has joined ##openfpga
<cr1901>
clifford: Well, I asked azonenberg b/c I didn't want you to realize that I didn't know why your hello1.v didn't work until yesterday :P.
specing has quit [Ping timeout: 240 seconds]
specing has joined ##openfpga
scrts has quit [Ping timeout: 248 seconds]
scrts has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
scrts has quit [Ping timeout: 276 seconds]
scrts has joined ##openfpga
pie_ has quit [Ping timeout: 276 seconds]
DingoSaar_ is now known as DingoSaar
azonenberg_work has quit [Ping timeout: 258 seconds]
pie_ has joined ##openfpga
massi__ has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 248 seconds]
scrts has joined ##openfpga
digshadow has quit [Ping timeout: 276 seconds]
scrts has quit [Ping timeout: 240 seconds]
test123456 has joined ##openfpga
scrts has joined ##openfpga
m_w has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
scrts has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
coino has joined ##openfpga
scrts has quit [Ping timeout: 246 seconds]
* coino
o/
eduardo_ has quit [Ping timeout: 260 seconds]
eduardo_ has joined ##openfpga
<pointfree>
awygle, rqou: MRAM (Magnetoresistive RAM) is cooler than FRAM.
<pointfree>
Everspin MRAM appears to be slightly cheaper than Cypress FRAM
<pointfree>
'MRAM [Magnetoresistive RAM] has similar performance to SRAM, similar density to DRAM but much lower power consumption than DRAM, and is much faster and suffers no degradation over time in comparison to flash memory. It is this combination of features that some suggest makes it the “universal memory”, able to replace SRAM, DRAM, EEPROM, and flash.' - wikipedia
<pointfree>
Now the answer to everyone's burning question: It looks like STT-MRAM is capable of in-memory computation like DRAM https://arxiv.org/abs/1703.02118
<rqou>
oh btw azonenberg: instead of doing adders like i'm supposed to, i just played with extracting TFFs and it seems to work just fine
<rqou>
unfortunately extracting counters from TFFs is much trickier
<pointfree>
Of course neither the DRAM manufacturers nor Everspin are taking advantage of this in their memory controllers.
scrts has quit [Ping timeout: 246 seconds]
ZipCPU_ has joined ##openfpga
ZipCPU has quit [Ping timeout: 260 seconds]
DingoSaar_ has joined ##openfpga
ZipCPU_ is now known as ZipCPU
DingoSaar has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<rqou>
unfortunately the TFF extraction i've written is a bit too aggressive for normal synthesis flows i think
DingoSaar_ is now known as DingoSaar
scrts has quit [Ping timeout: 240 seconds]
coino has joined ##openfpga
scrts has joined ##openfpga
<felix_>
rqou: i requested a voucher; i'll pm you when i get the email
<rqou>
great, thanks a lot
azonenberg_work has joined ##openfpga
DingoSaar has quit [Remote host closed the connection]
DingoSaar has joined ##openfpga
<azonenberg_work>
rqou: ping
<rqou>
pong
<azonenberg_work>
What is the current status of your adder extraction script? Can you share the code/copmmands?
<azonenberg_work>
commands*
<azonenberg_work>
wanted to use it as a base for finding other stuff
<rqou>
herp derp, i was messing with extracting TFFs
<azonenberg_work>
ah ok
<rqou>
extracting TFFs does work
<rqou>
unfortunately:
<rqou>
> unfortunately the TFF extraction i've written is a bit too aggressive for normal synthesis flows i think
<azonenberg_work>
i wanted to do a shregmap followed by another pass to turn shregs back into multi-bit registers
<azonenberg_work>
Oh?
<rqou>
it needs to run the "giant abc hammer" twice
<rqou>
which totally destroys any structure in the combinatorial logic you had before
<azonenberg_work>
Lol
<azonenberg_work>
FWIW, my current approach does that for other stuff anyway
<azonenberg_work>
i dont care what the original structure is
<rqou>
and of course yosys doesn't currently have tff builtins, so it doesn't print out usable verilog
<rqou>
for RE you probably don't, but for synthesis you might
<azonenberg_work>
True
<azonenberg_work>
But isn't this a RE-focused pass?
<rqou>
since you're the one who complained that you didn't really like netnames of $abc.cc$foobarbaz
<rqou>
heh, it works in the synthesis direction too :P
<azonenberg_work>
Worrying about TFF extraction for synthesis is a whole other story
<azonenberg_work>
and one i dont care about for now
<rqou>
i mean, it does work
<azonenberg_work>
Yeah
<rqou>
it's not significantly worse than the current procedure of running abc
<azonenberg_work>
Yeah
<rqou>
but alright, i'll go and actually turn my half-working commands into a real yosys script
<azonenberg_work>
Fixing the $abc.cc.$foobarbaz netnames in forward synthesis is definitely on my wishlist, but lets focus on getting the RE stuff working first
<azonenberg_work>
if we start from a bitstream we have no netnames anywa
<azonenberg_work>
anyway*
scrts has quit [Ping timeout: 260 seconds]
<rqou>
right, but for now worse case i don't really mind using the tff script for the coolrunner-ii backend
<rqou>
because "abc -sop" already destroys any semblance of the original structure
<rqou>
er wait
<rqou>
it's actually quite a bit suboptimal for synthesis right now
<rqou>
because dfflibmap won't work on the tff cells
<azonenberg_work>
let's focus on RE for now
<azonenberg_work>
Synthesis happens after we get the con talk out of the way :)
<rqou>
the paper that i stole the adder extraction idea from was actually using it for synthesis
<rqou>
they also made improvements to the vpr packer that we don't care about right now
<azonenberg_work>
Link to the paper?
<rqou>
argh, i'll find it later
<rqou>
lost among my tabs
<lain>
need the ability to search tabs
<rqou>
the TL;DR of the paper is just "AIGs make it really easy to extract out parts of the logic that look like XOR3/majority gates"
<rqou>
they were using a custom ABC pass to do that, but i felt that that was too difficult
<rqou>
so the trick i came up with is "what if i tell abc to do normal techmapping to asic cells, but the only cells i give it are NOT, AND, and the cells i'm looking for?"
scrts has joined ##openfpga
<rqou>
it'll then try to find "the cells i'm looking for," and there's nothing else abc can use, so the rest of the design stays as an AIG
<azonenberg_work>
Lol, that works
<rqou>
then once we're done doing whatever work on the cells ABC extracted, we can just run abc again with the normal cell library and the stuff that was turned into an AIG turns back into something sane
<azonenberg_work>
Makes sense
<rqou>
and i didn't even have to write any code
<azonenberg_work>
So i think what i'm going to do is
<azonenberg_work>
shregmap
<azonenberg_work>
then techmap shregs back into dffs
<azonenberg_work>
but first do some stuff to group the outputs of the shreg back into a multi-bit vector
<rqou>
yeah, sounds good
<rqou>
unfortunately i find yosys sigbit/sigspecs a bit confusing to work with
<azonenberg_work>
yeah they can be a bit tricky
<azonenberg_work>
i want to try to make a unified "infer vectors" pass
<azonenberg_work>
that i can call with various args to figure things out
<azonenberg_work>
For example: the output of an adder is a vector
<azonenberg_work>
the output of a shreg is a vector
<azonenberg_work>
etc
<azonenberg_work>
I also need to make a pass to optimize out top-level ports that are not being used
<azonenberg_work>
iow if there is no ibuf or obuf on the port, delete the port
<azonenberg_work>
Since my default code right now creates a top-level port for every pad on the die
<azonenberg_work>
i also have to push multi-bit vectors out to vector top level ports
<azonenberg_work>
And i have to make something that's basically the inverse of attrmvcp
<azonenberg_work>
i.e. moves attributes from iob cells to top level port wires
<rqou>
yeah, i need all those passes too
test123456 has quit [Quit: Leaving]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<awygle_m>
Is the talk going to be recorded?
DingoSaar has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 248 seconds]
GenTooMan has joined ##openfpga
DingoSaar has joined ##openfpga
scrts has joined ##openfpga
m_w has quit [Quit: leaving]
scrts has quit [Ping timeout: 240 seconds]
coino has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
coino has joined ##openfpga
<balrog>
cyrozap: can you join ##PSoC ?
<pointfree>
Are these AIG's using quantifiers? Is there a reason why not? I was oblivious to them until rqou told me about them yesterday.
<rqou>
i actually don't know
<rqou>
read the abc paper? :P
<rqou>
i'm currently using abc as just a black box of "logic goes in, cells come out"
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
DingoSaar has quit [Remote host closed the connection]