<mkdir>
alright Xark, I got it working on my little boat :)
<Xark>
mkdir: Cool. I just got mine working (again). :)
<mkdir>
very nice, yeah it something was wrong with my date + time so my apt-update was not working properly
<mkdir>
because it was not working properly, libftdi-dev was not installing properly
<Xark>
mkdir: Ahh, I can see that being confusing
<mkdir>
yeah the time zone was correct but somehow the time was off (strange) must have been some mistake when I setup my VM
<mkdir>
also strange is that most people with my same libftdi error reported that it happened to them because they had a linux32 version or something
<mkdir>
making the whole situation ever more confusing lol
<mkdir>
but I'm glad it works. I have two cool dev boards now that I can develop on. papilio and ice40 stick. these should keep me busy for a while
<Xark>
mkdir: Other than ISE, Papilio Pro is decent. :)
<mkdir>
good to hear, yeah it was the first board I purchased. I hate using the fat ISE but it's the only way to compile my verilog for spartan6 lol
<mkdir>
so it will be nice to have a popular FPGA as well as one that handles open src tools
<Xark>
mkdir: Yep. Kind of seems sprightly next to Vivado...
<Xark>
mkdir: The open tools have been pretty sweet on this little up5k board I am playing with (IceBreaker). Should be same on icestick (just smaller FPGA).
<mkdir>
yeah i'll probably get an artix-7 for vivado when I get a little more experienced
<mkdir>
nice does that have an ice40 on it too?
<Xark>
mkdir:Yes, ice40 variant. Has 128KB of embedded "SPRAM" and is lower power (I think).
<mkdir>
ooh nice, does icestick even have onboard ram?
dj_pi has quit [Ping timeout: 268 seconds]
<mkdir>
nah i guess not
Bike has quit [Quit: Lost terminal]
Bob_Dole has joined ##openfpga
Richard_Simmons2 has quit [Ping timeout: 276 seconds]
<Xark>
mkdir: This is BRAM, aka Block RAM embedded in the the FPGA. Most non-tiny FPGAs have some.
<mkdir>
ah I see, yeah I was guessing perhaps in the fpga, didn't see it on the board
<Xark>
mkdir: Some boards have external RAM too, of course (i.e., SRAM, SDRAM, DDR etc.)
<mkdir>
yeah definitely, the papilio pro has a SDRAM
<Xark>
mkdir: Right, it also has (IIRC) 64KB of internal BRAM. Kind of like FPGA "cache RAM" (kind of...)
<mkdir>
hmm interesting
<mkdir>
bram is always inside right?
Bob_Dole has quit [Ping timeout: 252 seconds]
<mkdir>
is there ever external bram
<Xark>
mkdir: No I don't think so (if it is external, it would just be really really fast SRAM).
<mkdir>
true
<Xark>
mkdir: BRAM also tends to be very flexible too. So, you can configure it to be really wide memory, or multiple inpendent blocks that are accessed in parallel.
<mkdir>
and expensive af
<Xark>
That too. :)
<mkdir>
that's cool, how is bram different from the clb's
<mkdir>
logic blocks, from what I understand clb's are for operation where as BRAM for memory stor
<Xark>
mkdir: It is a different "flavor" of block that is a little chunk of clocked SRAM. You can use CLB to make "distributed memory" (typically), but it is less efficient (and burns flip-flops for storage),
<Xark>
(Hmm, actually that pic might not be 1K...but the text is)
<Xark>
(and same idea)
<mkdir>
good article thanks
<mkdir>
do you know about RISC-V
<mkdir>
is it good? I mean we all love it cause it's open src
<mkdir>
v cool
<sorear>
calling risc-v "open source" is a category error
<Xark>
mkdir: It is a fine open ISA. :)
<sorear>
it's a trademark for a specification. it's like asking if IEEE 754 is open "source"
<mkdir>
sorear true, but it's really the only open source isa out there
<Xark>
mkdir: No, but it seems to have the momentum.
<sorear>
how can something with no source code be open source
<sorear>
risc-v is an *open standard* in the same sense as e.g. AV1 (specification available to all and not patented)
<mkdir>
oh there is no verilog or vhdl "code" out there for RISC-V?
<Xark>
mkdir: There is, but those are an implementation of the open risc-v standard.
<mkdir>
Xark, I guess there are probably others yes
<mkdir>
mmm i feel
<sorear>
there is verilog and vhdl code available for various cores that implement risc-v
<sorear>
it's correct to say that those cores (rocket, ariane, picorv32, vexriscv, etc etc) are open source
<sorear>
there are also non-open-source riscv-compliant cores
<sorear>
it's not the first open ISA, I've seen attempts to build communities around or1k, sparc v8, super-h, and lm32, but this is the first that's gotten buy-in from more than a handful of groups
<mkdir>
ah ok, my b. Yeah I don't no much about RISC-V tbh
<mkdir>
know*
<mkdir>
interesting
<mkdir>
i see how you mean now that it is a standard like IEEE standard or IETF standard
<sorear>
SPARC v8 is literally an IEEE standard
<mkdir>
very interest, from Sun Microsystems huh who would have thought
Bob_Dole has joined ##openfpga
<sorear>
yeah, this happened in the late years shortly before the Oracle buyout
<sorear>
Sun published the design of the UltraSPARC T1 and T2 chips under the GPL, and the V8 ISA as an open standard
<sorear>
oracle didn't continue that; the M-series UltraSPARC are in no sense open source, and the V9 ISA has patent issues
<Xark>
mkdir: IMHO it helps that RISC-V is a competent ISA. Minimal and "easy" to implement (relatively), but well thought out. It has a few good ideas baked into it, while avoiding some older bad ideas.
<kc8apf>
T1 wasn't a particularly great CPU
<kc8apf>
And UltraSPARC carried a lot of legacy oddities
<sorear>
then the open sparc v8 users are … afaik, just OpenPiton (Princeton NoC research platform) and LEON (Cobham Gaisler's specialty high-reliability designs for the space market)
<mkdir>
cool to know about all these ISA's lol
<mkdir>
so openpiton is an implementation of open sparc v8?
m4ssi has joined ##openfpga
<sorear>
not independently, they made it by modifying the ultrasparc t1 code release
rohitksingh_work has joined ##openfpga
<sorear>
(heavily modifying the cache system, but not much else)
<mkdir>
oh I see
<mkdir>
heading to bed, thanks for all the info. Xark, that hackaday article is a good resource for my icestick dev goals, much appreciated.
<Xark>
mkdir: My pleasure. Take it easy.
<mkdir>
thanks you too, tell me more about the icebreaker next time we talk
<whitequark>
>No one seems to like latches in design, though they are faster, and take lesser transistor. This is due to the fact that timing analysis tools always have problems with latches; glitch at enable pin of latch is another problem
<whitequark>
are they really that nice, assuming we have a magic timing analysis tool that can cope with them?
<daveshah>
Yes, I think so
<whitequark>
huh interesting, can you explain?
<daveshah>
I read something about a bitcoin miner that used latches
<whitequark>
because I don't really get *why* are they so nice