azonenberg_work has quit [Ping timeout: 245 seconds]
cr1901_modern has quit [Ping timeout: 272 seconds]
jcarpenter2 has joined ##openfpga
emeb has quit [Quit: Leaving.]
C_Elegans has quit [Ping timeout: 258 seconds]
cr1901_modern has joined ##openfpga
azonenberg_work has joined ##openfpga
dj_pi has joined ##openfpga
azonenberg_work has quit [Ping timeout: 272 seconds]
balrog_ has joined ##openfpga
xdeller_ has joined ##openfpga
jn___ has joined ##openfpga
dj_pi has quit [*.net *.split]
balrog has quit [*.net *.split]
jn__ has quit [*.net *.split]
xdeller has quit [*.net *.split]
balrog_ is now known as balrog
jn___ is now known as jn__
<whitequark>
ZipCPU: so I have a major problem with k-induction, which is that it just always passes.
<whitequark>
I have no idea how to make it fail. my design is obviously broken.
unixb0y has quit [Ping timeout: 246 seconds]
unixb0y has joined ##openfpga
<whitequark>
hmm, I think I worked out the issue, an off-by-1
Miyu has quit [Ping timeout: 250 seconds]
rohitksingh_work has joined ##openfpga
Bike has quit [Quit: sleeping]
_whitelogger has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 245 seconds]
unixb0y has quit [Ping timeout: 246 seconds]
unixb0y has joined ##openfpga
azonenberg_work has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 245 seconds]
jcarpenter2 has quit [Quit: Leaving]
rohitksingh_work has joined ##openfpga
s_frit has joined ##openfpga
_whitelogger has joined ##openfpga
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 246 seconds]
rohitksingh_wor1 has quit [Quit: Leaving.]
rohitksingh_work has joined ##openfpga
m4ssi has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ZipCPU|Laptop has joined ##openfpga
ayjay_t has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
Miyu has joined ##openfpga
tlwoerner has quit [Quit: Leaving]
rohitksingh has joined ##openfpga
tlwoerner has joined ##openfpga
emeb has joined ##openfpga
<tnt>
I'm trying to understnad the timing for oruting in icebox, but I'm having a few questions that aren't obvious. For instance : There is Span4Mux_h0 to Span4Mux_h4. which I guess depends on the distance ? But then why is there 5 of them ? or is there somehow a distance 0 where you output and input on the same one ?
rohitksingh has quit [Ping timeout: 246 seconds]
<sxpert>
do we have something that I could use as a time-exact emulator ?
<tnt>
icetime can output a verilog netlist from a .asc but not sure if there are models with timing info for the various subelements it uses.
<sxpert>
I was thinking of that thing with a graphic representation they have in ISE
<tnt>
well that's just a simulator, it's not necessarely time-exact.
m4ssi has quit [Ping timeout: 272 seconds]
<sxpert>
ah
<sxpert>
ok, so do we have something that replaces that ;)
<tnt>
(i.e. unless you give it a post pnr netlist, it just simulates the verilog)
<tnt>
sure, iverilog and verilator. And gtkwave for viewing the resulting simulation results.
<sxpert>
ok thanks
* sxpert
will look
m4ssi has joined ##openfpga
m4ssi has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
m4ssi has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
ZipCPU|Laptop has quit [Ping timeout: 272 seconds]
rohitksingh has quit [Remote host closed the connection]
mifune_ is now known as mifune
mifune has quit [Changing host]
mifune has joined ##openfpga
Sellerie_ has joined ##openfpga
Sellerie has quit [Quit: leaving]
Sellerie_ is now known as Sellerie
ZipCPU|Laptop has joined ##openfpga
_plant is now known as catplant
Stary has quit [Ping timeout: 252 seconds]
Bike has joined ##openfpga
X-Scale has quit [Ping timeout: 268 seconds]
mkdir has joined ##openfpga
<mkdir>
Hi, what is block ram and is it unique to only FPGAs?
<mkdir>
anyone?
<tnt>
it's just RAM ...
<tnt>
static ram to be exact.
<mkdir>
thanks, it's SRAM?
<tnt>
yup
<mkdir>
how about distributed ram
<mkdir>
is that dynamic ram?
<tnt>
nope, it's also static ram.
<tnt>
just usually _much_ smaller.
<tnt>
so you have a whole lot of very small ram cells instead of (or rather in addition to) a few big ram cells.
<mkdir>
Oh I see, I'm just trying to wrap my head around the differences of block ram vs regular ram
<mkdir>
and by regular ram i mean whatever intel is suing
<mkdir>
using
<mkdir>
cpu ram
<sorear>
block ram is technologically no different from what intel cpus use for caches etc
<tnt>
normal pc ram is dynamic ram, very different beast.
<tnt>
in fpga we call it 'bram' because it come in small-ish indepedent "blocks".
<mkdir>
i see, is one superior to the other? What are the tradeoffs?
<tnt>
but it's just static ram , sometime dual-ported, sometimes not, sometime true-dual port, ...
<daveshah>
It probably even comes from the same memory compiler
<tnt>
"block ram" comes in many different variant depending on the fpga vendor / device.
<sorear>
dynamic ram, the kind that comes on sticks and you put in a PC, is optimized to be very cheap per byte
<mkdir>
Oh ok very helpful thanks
<sorear>
a *very* expensive FPGA might have 90 MB of block ram, (total, split between thousands of blocks)
<sorear>
most FPGAs can also talk to external PC RAM
<mkdir>
oh interesting
<mkdir>
how do memory lookups work in fpgas
<mkdir>
I know the instruction cycle is common in cpus
<tnt>
dynamic ram is often much larger but (1) you need to 'refresh it' from time to time or the content progressively degrades (2) it's designed for burst access (i.e. ready many bytes from consecutive adress), doing random access kills performance
<mkdir>
I imagien it's different in fpgas though
<daveshah>
You give it an address, and between 0 and 2 clock cycles later you get data
<daveshah>
Depending on the FPGA and config
<daveshah>
Distributed RAM is usually asynchronous so has a delay but doesn't add any clock cycles of latency
<mkdir>
ah tnt, very good to know. I must read up on static vs dynamic ram tradeoffs then it seems
<daveshah>
BRAM almost always needs one or more clock cycles to read (often configurable)
<mkdir>
davesha, all the data stored?
<daveshah>
All modern FPGA RAM needs a clock cycle to write
<mkdir>
daveshah*
<sorear>
seems like you're fairly new to FPGAs in general. a FPGA consists of thousands/millions of basic elements (warning: terminology is not consistent between vendors), and millions of wires which can be individually configured to connect to the basic elements and each other
<sorear>
each element does one simple operation continuously
<sorear>
"lookup tables" compute a logical function of, typically, 4 or 6 inputs
<mkdir>
yes i am indeed new to the fpga world
<sorear>
"registers" store one bit of data, and update on a clock edge
<mkdir>
I'm familiar with cpu architectures but not as familiar with fpgas, is there a good resource you recommend?
<mkdir>
so that I'm not total newb
<Thorn>
mkdir: get Harris & Harris and read it a few times from cover to cover
<sorear>
"block RAM" stores a few thousand bits of data, has address and data inputs, and can normally do 2 random accesses in every clock cycle
<mkdir>
ty
<mkdir>
I see
<Thorn>
you're most likely a programmer and this is a different profession
<mkdir>
very interesting
<mkdir>
unfortunately, yes but not a simple python programmer
<mkdir>
c / low level / firmware
<sorear>
distributed RAM typically stores *tens* of bits, it occupies an intermediate role between registers and block RAM
<mkdir>
does Harris & Harris explain differences mention fpga?
<tnt>
best thing you can do is forget all your training :p thinking like a sw programmer is the best way to get crappy hdl designs imho.
<mkdir>
mm i see what type of thinking is best for hdl?
<tnt>
mkdir: think of how you'd build what you want with 7400 series chips :)
<Thorn>
I've seen an article a few months ago, something like "how to add verilog to your skill set if you're a java developer"
<sorear>
Thorn: title of book?
<Thorn>
that's like adding civil engineering or marine navigation to your skillset as.a java dev
<tnt>
Then you end up with a led blinker that fits in a ultrascale :p