azonenberg_work has quit [Ping timeout: 244 seconds]
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
rohitksingh has joined ##openfpga
<Sprite_tm>
azonenberg: https://www.libssh.org/ may be of use to you. No experience, but I think someone ported it to the ESP32, so it can do at least some embedded stuff. Should also have a server side.
<whitequark>
azonenberg wants an ssh in gateware
rohitksingh has quit [Ping timeout: 250 seconds]
<Sprite_tm>
whitequark: You sure?
<Sprite_tm>
19:05 < azonenberg_work> first round firmware will be rs232 only, then i'll bring up telnet, then eventually ssh
<Sprite_tm>
19:05 < azonenberg_work> that will probably take a while as i dont think anyone makes a sshd that runs on a bare metal system with no filesystem or dynamic memory allocation
<whitequark>
oh hm
<emily>
ssh in gateware sounds like fun
<Sprite_tm>
emily: I'd posit that very much depends on your personal definition of the concept 'fun'.
rohitksingh has joined ##openfpga
<emily>
; w;
freemint has quit [Ping timeout: 250 seconds]
freemint has joined ##openfpga
emeb_mac has quit [Ping timeout: 248 seconds]
freemint has quit [Ping timeout: 250 seconds]
emeb_mac has joined ##openfpga
<GenTooMan>
Anyone know of a way to force icarus to output the preprocessor output? macro's in verilog are pretty tricky without it.
_whitelogger has joined ##openfpga
<azonenberg>
i do also want to do ssh in gateware
<azonenberg>
but not for this project
Flea86 has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
futarisIRCcloud has joined ##openfpga
Bike has quit [Quit: Lost terminal]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
azonenberg_work has joined ##openfpga
Flea86 has quit [Ping timeout: 248 seconds]
Flea86 has joined ##openfpga
rohitksingh has quit [Ping timeout: 264 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
Jybz has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
MarcelineVQ has quit [Read error: Connection reset by peer]
MarcelineVQ has joined ##openfpga
emeb_mac has quit [Ping timeout: 245 seconds]
pie_ has quit [Ping timeout: 252 seconds]
Thorn has quit [Ping timeout: 272 seconds]
Thorn has joined ##openfpga
pie_ has joined ##openfpga
Maylay has quit [Ping timeout: 268 seconds]
Maylay has joined ##openfpga
MarcelineVQ has quit [Read error: Connection reset by peer]
MarcelineVQ has joined ##openfpga
Flea86 has quit [Quit: Leaving]
freemint has joined ##openfpga
unixb0y has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
pie_ has quit [Quit: pie_]
pie_ has joined ##openfpga
CounterPillow has quit [Quit: Bye.]
CounterPillow has joined ##openfpga
freemint has quit [Ping timeout: 250 seconds]
freemint has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
freemint has joined ##openfpga
emeb has joined ##openfpga
genii has joined ##openfpga
tlwoerner has quit [Ping timeout: 268 seconds]
tlwoerner has joined ##openfpga
genii has quit [Quit: Dammit Mitch]
<davidc__>
Does anyone know how mature the ECP5U support is? From the looks of twitter, people are doing successful designs with the open toolchain.
<davidc__>
(IE, would I be insane for laying out a board with an ECP5 and DDR2 and expecting it to work with a open-tools created bitstream?)
<daveshah>
afaik the only problem you will have is litedram missing a DDR2 PHY for ECP5
<davidc__>
(assuming the verilog would work if given to Diamond with plenty of timing margin)
<daveshah>
(it has a DDR3 one which could probably be adapted)
<davidc__>
Eh, DDR3 would be fine for my needs. I'd misread it and assumed DDR2
<davidc__>
DDR3 is cheaper these days anyhow
<daveshah>
If using DDR3 I would recommend getting the "-8" graded parts (or even the 5G ones if budget allow, these have even faster fabric as well as transceivers)
<davidc__>
I'm trying to drive the BoM cost down as much as I can (OSHW project, and I'd like them to be affordable). So I'll proably take a look at the price tradeoffs
<whitequark>
I've also made a fully FOSS PCIe PHY, though it is very unfinished yet
<davidc__>
-8 pricing isn't unreasonable, 5G is a bit spendy.
pie_ has quit [Ping timeout: 252 seconds]
<daveshah>
5G is probably 15-20% faster fabric than "-8" (and the BRAM clock-to-out is 2x faster), because it is specced for 1.2V core rather than 1.1V
<davidc__>
I'll grab an eval board and see what I can get working. Anyone have a ECP5 board they can recommend?
<daveshah>
If you want DDR3 the Versa is probably the best choice
<davidc__>
daveshah: I don't think this is perf-critical; would be replacing a S6 using SDRAM
genii has joined ##openfpga
Bob_Dole has quit [Read error: Connection reset by peer]
Bob_Dole has joined ##openfpga
genii has quit [Remote host closed the connection]
mumptai has joined ##openfpga
genii has joined ##openfpga
_whitenotifier-3 has quit [Remote host closed the connection]
<mithro>
People who are doing ECP5 open hardware should reach out to me, I have some connections that might be able to get you better pricing...
<daveshah>
mithro: I think you've discussed that with folknology already?
<daveshah>
He has an ECP5 board in the works
<mithro>
I did but it dropped off my radar
<mithro>
I can only really help with whole reels / trays
<tnt>
How many is in a tray ?
<daveshah>
About 100 iirc
<sensille>
mithro: interesting, planning to do a stepper controller board with ECP5 soonish
<freemint>
For what use cases is the power architecture interesting?
<ZirconiumX>
Power itself isn't all that interesting
<ZirconiumX>
The chips themselves are interesting because of their very wide SMT
<freemint>
It would be interesting if we take the open sourced OPEN POWER implementation which grants us some IBM patents and then change the ISA a bit to better fit our needs.
<ZirconiumX>
Then it wouldn't be Power anymore
<ZirconiumX>
At that point you might as well use RISC-V which is royalty-free from the start
<freemint>
The thing should still be covered under IBM patents, because of the exhaustion doctrine.
<freemint>
(In the US)
<ZirconiumX>
What happened to your experiments with SuperH, anyway?
<freemint>
I am only a user, currently. (Porting a real time kernel to t) but i aim to become more active in the vhdl soon.
<freemint>
I think i found a way of improving the behavior of the interrupt controller but i have to wait what the J-Core people say about it.
<freemint>
Patent exhaustion doctrine + open source (depending on stuff we have to wait to see) would basicly allow us to morph an Power implementation that has patents granted from IBM in what ever we want and it would still be free from litigation from these patents. This despends on the license and stuff i do not know yet but it would be interesting.
<freemint>
(obligatory not a lawyer, may only apply in US)
<freemint>
the patent law affords no basis for restraining the use and enjoyment of the thing sold." Where sold can also mean given away for free under the condition that you obey this open source license.
<freemint>
I have an FPGA board running the SuperH clone.
<freemint>
Anyway i am curious under what license they release it
<freemint>
Oh they are aware of this: they endorse modifying the power isa
<ZirconiumX>
Apparently MIPSr6 is still not all that "open"
<freemint>
The softcore implementation of the Power ISA, in particular, should give developers more control and even enable them to build their own instruction sets, Hugh Blemings, executive director of the OpenPower Foundation explained. “They can now actually try crafting their own instruction sets, and try out new ways of the accelerated data processes and so forth at a lower level than previously possible,” he said.
<freemint>
- quote from techcrunch.com
emeb has left ##openfpga [##openfpga]
<freemint>
I have no idea what that will mean but i am excited
<mithro>
freemint: If you added j-core to litex-buildenv, you are likely to get a few more users... I added a toolchain to conda so the peices are there
<mithro>
freemint: I know Hugh Blemings from the Australian open source community, he is a true open source believer and been around the Linux community since long before myself
<mithro>
FYI - I'm at the hardware hacking village at CCCamp19 right now!
<freemint>
mithro, i missed that chance to get a ticket
<freemint>
I will talk about litex-buildenv with the J-Core people. I am really just starting to be an active community member there
<freemint>
Where can i learn litex-buildenv to see if excites me?
X-Scale has quit [Read error: Connection reset by peer]
<freemint>
I have found nothing on VHDL there.
<whitequark>
VHDL is not really used much with open-source tools for a variety of reasons
<freemint>
Oh why?
<freemint>
(where can i read about the reasons)
<whitequark>
a) it is very hard to write a VHDL frontend, a number of attempts have failed or been abandoned
<whitequark>
b) there are very few open-source tools for VHDL compared to Verilog
<whitequark>
c) chicken and egg problem because of the above
<oeuf>
chickend and me
<oeuf>
s/end/en/
<whitequark>
for example Yosys only supports VHDL with a commercial frontend
<freemint>
Mhh, J-Core is written VHDL. :(
<whitequark>
I think the underlying reason is ... well
<whitequark>
in spite of Verilog being truly awful on many levels, people dislike VHDL even more
<freemint>
Oh, i got a lot to learn
<whitequark>
I personally dislike either of them well enough to maintain a HDL on my own (nMigen)
<freemint>
My respect
<whitequark>
SystemVerilog has a similar situation to VHDL btw
<whitequark>
few open-source tools support SystemVerilog properly, it's usually a dozen cherry picked features
<freemint>
This is sad.
<whitequark>
similarly, my theory is that the people who contribute to FOSS tools are correctly considering SV an awful language and therefore do not itch to improve support for it
<freemint>
Mhh there are several reason to go with VHDL for me at the moment.
<whitequark>
whereas industry has both inertia and the situation where your job requires a specific language so you don't have a choice
<freemint>
In think things are a bit different in Germany here than in the OS.
<whitequark>
i am not in the US.
<freemint>
Ok
<freemint>
Why is VHDL awfull?
<whitequark>
I didn't say it's awful
<whitequark>
I did say I dislike it, for two reasons
<whitequark>
first, it's way too verbose
<whitequark>
second, it's a general purpose event simulator language that uses inference to map to synchronous logic
<whitequark>
and I believe that a HDL used primarily for synchronous logic should, well, directly support synchronous logic
<whitequark>
one thing that really makes VHDL stand out (in a good way) is its deterministic simulation model
<freemint>
I am a bit more hopefull for open VHDL tooling. In the OPENPower presentation there was a lot of focus on making open tool chains and the first openpower core "microwatt" is running in VHDL.
<freemint>
(Just watching the presentation.)
<whitequark>
well, my personal view (which some may consider extreme) is that both (System)Verilog and VHDL are dead ends
<freemint>
I get that position.
<Morn_>
well there are no replacements for vhdl or verilog when it comes to netlist or timing simulation, are there?
<freemint>
"dead end" or "dead end for open source hardware"
<whitequark>
freemint: both
<whitequark>
it's certainly possible to improve VHDL OSS tooling to the level of Verilog OSS tooling
<freemint>
But if that would happen VHDL would still be a dead end?
<whitequark>
Morn_: looking only at industry standard tools: EDIF?
<whitequark>
freemint: yep
<whitequark>
for synchronous designs that is
<whitequark>
I don't have any answer for highly asynchronous designs at all
<Morn_>
is there an open source simulator that can simulate edif?
<freemint>
Oh EDIF is in S-Expr , nice
<Morn_>
i feel like one should just scrap all the old eda standards and start over from scratch
<whitequark>
that's kind of what i'm busy doing :p
<whitequark>
(though you can still ask Yosys to emit Verilog if you need it for legacy toolchains like Vivado)
<whitequark>
I don't think any OSS tools currently can do post-PNR timing simulation at all
<freemint>
What do you do to make sure to not run in to this: https://xkcd.com/927/ ?
<whitequark>
i don't. it's inevitable
<whitequark>
this is like trying to replace C, another laudable goal. you'll never replace *all* C, all you can hope is to convince people just entering the industry that they don't actually have to suffer
<freemint>
Do you have other people comment on your designs?
<Morn_>
I think Icarus Verilog can do timing annotated simulation
<whitequark>
Morn_: yes but i don't think you can get the annotated verilog from anywhere
<whitequark>
and the thing about verilog is that it's an even worse interchange format than programming language
<whitequark>
like, "structural verilog" isn't a thing. a single thing anyhow. no one can agree what it is
<whitequark>
you're basically stuck emitting the lowest common denominator of the verilog accepted by every tool you're interested in, which is an inherently open ended set
<whitequark>
and of course every application has to do the netlist transformations to degrade it to that level itself
<freemint>
How do you make sure your are not just creating a solution that fits your local niche?
<mwk>
freemint: FWIW edif is another horrible standard
<Morn_>
yeah i see that that is crappy from a tooling development standpoint
<daveshah>
No it isn't
<daveshah>
edif isn't a standard :p
<Morn_>
:D
<whitequark>
lol
<mwk>
mostly because everyone implements it differently
<mwk>
yeah
<freemint>
Is there something that does not suck?
<whitequark>
freemint: I am, that's the whole point of nMigen: fit the niche of "language for describing synchronous logic"
<GenTooMan>
freemint are you trying to narrow things way down to like 1 or 2?
<whitequark>
which is ... an extremely large niche, really
<mwk>
freemint: broken vacuum cleaners
<whitequark>
one of major problem with Verilog is that it tries to be everything at the same time, which makes it really bad at a wide array of things
<whitequark>
just read the spec
<whitequark>
or skim it i guess
<Morn_>
there are advantages to having rtl and netlist in the same format though
<mwk>
um
* mwk
kind of thinks there are reasons why we don't have HLL and assembly language code in the same format
<whitequark>
^
<Morn_>
what if i want to have part of a design in rtl and another part as netlist and simulate them together?
<emily>
freemint: whitequark's niche is pretty big
<emily>
have you seen glasgow
<emily>
what if i want to have part of a design in c++ and another part in assembly and link them together
<whitequark>
^
<freemint>
I guess so, reading up on "synchronous logic"
<whitequark>
an RTL simulator and a netlist simulator are fundamentally different beasts
<whitequark>
for example, compare the approaches iverilog and verilator take
<Morn_>
well if you have only rtl you can speed things up greatly, but what if you have both?
<whitequark>
either a) you translate rtl to netlist, or b) you link the simulators on a higher level
<whitequark>
this, by the way, is true even if you have everything in verilog
<whitequark>
if you have an arbitrary netlist you can't feed it to verilator
<Morn_>
in verilog you can just simulate everything together as intended in the standard
<freemint>
What does RTL mean?
<mwk>
register transfer level, Verilog code using processes etc. basically
<mwk>
(or VHDL)
<whitequark>
Morn_: iverilog internally lowers both RTL and netlist to some sort of IR it has
<whitequark>
if you make this step explicit you don't lose anything
<Morn_>
that IR must be a bit more than gate-level netlist thought, doesnt it?
<whitequark>
I'm not sure exactly what iverilog uses
<whitequark>
but consider this: Yosys' RTLIL can represent both processes and gates, and in fact expressions get transformed to gates directly (coarse gates, at least until you break them down) but synchronous logic gets transformed to processes
<whitequark>
you can gradually break down this representation to a lower level one, which is what synthesis does
<whitequark>
however, at any point, RTLIL is ~trivial to parse, and a complete RTLIL frontend and simulator is maybe a week of work.
<whitequark>
this is because it gets rid of all the irrelevant details in Verilog, like its batshit insane arithmetic rules
<Morn_>
i have not looked at RTLIL but it sounds cool
<whitequark>
(it doesn't have to be Yosys, FIRRTL is very similar)
<whitequark>
basically, you're correct that a shared representation for RTL and netlist is useful
<Morn_>
well maybe RTLIL is good
<whitequark>
but what's *not* useful (and is actively harmful) is having that representation also be your HDL
<whitequark>
the thing you write as a programmer.
<whitequark>
the simulator should never care about elaboration, arithmetic precedence, literals, and so on
<mwk>
see also: why LLVM IR != C and why LLVM IR != assembly language
<whitequark>
yeah
<Morn_>
hm yeah i am used to it from the commercial tools and it works, but i really would not want to reimplement any of that
<whitequark>
now you understand! :)
<whitequark>
commercial tools all either like, license Synplify, or implement some horrible hack that breaks constantly, or both
<whitequark>
Synplify is admittedly very good at implementing all the awful things in Verilog, which is also why it costs so much
<Morn_>
yeah
<freemint>
Is there a problem with closed source tool chains other than cost and restrictions for the sake of market segmentation? (Say if we had a millioniare here and bought everyone all the commercial tool we would want for our project would you still make your own HDL?)
<whitequark>
freemint: yes. for example, I have a project, Glasgow, which relies on generating bitstreams on demand and *quick*.
<whitequark>
the FOSS toolchain can generate an iCE40 or ECP5 bitstream faster than the proprietary toolchain can *start*
<whitequark>
i can also redistribute it but not the proprietary toolchain
<whitequark>
both because the EULA forbids it, and because it's like several fucking gigabytes
<somlo>
freemint: there's also the problem of being able to prove that the thing you get is equivalent (from a trust perspective) to the sources you built it from
<somlo>
can't do that with black-box tools you can't see the sources for AND rebuild yourself :)
<mwk>
freemint: another example
<mwk>
I'd very much like to have a tool that flashes SPI flash on my FPGA dev board via JTAG
<whitequark>
somlo: you can
<whitequark>
somlo: in fact if you look at seL4, they treat gcc as a black box
<mwk>
that's a simple thing: upload a simple bitstream to the FPGA that just passes commands from JTAG to SPI
<whitequark>
because auditing the source code of gcc or yosys is a) barely tractable if at all b) won't show you the bugs anyway
<whitequark>
what you do is you do equivalence checking between your hdl, rtl, and netlist
<mwk>
but to make such a thing generic, without knowing the exact FPGA model and board pinout a priori, you have to generate bitstreams on demand
<mwk>
which is absolutely non-viable with vendor tools
<sorear>
that requires the netlist format to be public
<freemint>
I totally endorse making an open source pipeline. I just wanted to understand your motivations,
<sorear>
sel4 wouldn’t have worked if the ISA was secret and they couldn’t write an equivalence checker
<mwk>
(there are a lot of FPGA boards where the SPI flash is connected to the FPGA *only* and you're supposed to flash the SPI through the FPGA, no way to connect an external programmer)
<whitequark>
sorear: but... it's public?
<whitequark>
you can tell vivado to give you a netlist full of primitives
<whitequark>
or do you want to guard against bitgen inserting a backdoor?
<mwk>
bitstream format, not netlist
<sorear>
do you want to distrust bitgen or nah?
<mwk>
I already distrust bitgen, that thing is cursed
<whitequark>
lol
<freemint>
So i am stuck with J-Core written in VHDL for now and am not in a position to have my own VHDL project (knowledge, etc..) What can/should i do in your opinion?
<whitequark>
what do you want to achieve exactly?
<freemint>
I wanted to give computing history a small nudge in a more open direction.
<mwk>
don't we all
<whitequark>
ok but in more concrete terms
<GenTooMan>
whitequark interesting idea mMigen I may mess with it sometime this evening when I am not knee deep in villainous verilog, I presume once you have the .blif file one can use the rest of the icestorm tools for creating the .bin file?
<whitequark>
GenTooMan: nmigen includes code for running the toolchain, too
<mwk>
heh
<whitequark>
you can synthesize, place, route, and program your design in 1 line
<mwk>
I really need to check out nMigen at some point
<mwk>
unfortunately, ever since I started working on FPGA tools I no longer have any opportunities to actually use them
<whitequark>
toolmaker's curse.
<whitequark>
you should get a glasgow
<whitequark>
that gives you an excuse to use the tools you're making to make other tools
<GenTooMan>
so basically you write a python program to do stuff. Too bad you can't use it for simulation ... that would be way cool I use iverilog / vvp to see if my verilog does what I think it will.
<whitequark>
it's basically the only reason i actually work on fpga designs these days lmao
<whitequark>
GenTooMan: you can
<mwk>
thus ending up in never-ending toolmaker recursion?
<whitequark>
nmigen includes a simulator
<whitequark>
mwk: precisely
<whitequark>
i believe in the last 5 years i havne't spent any time actually *doing* anything with the tools i maintain
<whitequark>
it's incredible
<whitequark>
ok maybe a few weeks
<whitequark>
but the ratio is that bad
<mwk>
reminds me when I wanted to play some stupid opengl game on my nvidia gpu
<whitequark>
right now i'm working on tools to work on tools to work on tools to work on tools.
<mwk>
I ended up as a gpu driver developer, briefly
<whitequark>
that's a mood
<mwk>
then I ended up writing gpu RE tools for a few years, so that other people can use that to write gpu drivers...
<whitequark>
hahaha
<mwk>
and then I had the bright idea to use an FPGA for reverse engineering some stupid shit on that gpu
<freemint>
I am in a position where i know people behind a tradeshow who develop a real time os. There are uncanny many ways how that tradeshow and J-Core fit together. I want to bring J-Core to that open source RTOS communities attention. Maybe i can give J-Core some commercial on silicon adoption.
<mwk>
that... didn't end well
<freemint>
That is my battle plan this year
<whitequark>
well, i'll be honest: that plan seems to be missing a few steps. like a dozen
<freemint>
Hit me with it
<whitequark>
like rtos people are usually not silicon people, and also people who want to tape out something to use it rarely use a design which has never seen a tapeout before
<freemint>
There are engineers in these companies who worked with SuperH before.
<whitequark>
but not j-core specifically
<freemint>
SuperH = J-Core + CAS
<whitequark>
it's a new implementation, with its own exciting bugs
<whitequark>
is it even written for ASICs?
<GenTooMan>
nwk I won't share your pain but I can empathize with doing things like that and them not ending well.
<Morn_>
what's better about j-core than all those open source risc-v cores?
<freemint>
It is written for asics from what i have heard. They target 180nm
<whitequark>
ah ok, that's better
<freemint>
About Risc-V: Better instruction set density, targets embedded and makes trade-offs for that. Less of a "we do AI, HPC, Desktop and embedded from our academic chair"-approach
<whitequark>
have you looked at rv32c?
<mithro>
VPR outputs a post PnR Verilog + SDF which can be simulated in a bunch of commercial tools (unsure if there are open tools which can do it)
<cr1901_modern>
I'd like to see a size benchmark between rv32c and superH
<Morn_>
me too
<whitequark>
rv32c and superh are arhitectures not implementations
<Morn_>
i mean like the size of some example code in rv32imc and superh for comparison
<whitequark>
ohh
<whitequark>
that's still affected by compiler maturity though.
<Morn_>
true
<freemint>
on both sides.
<cr1901_modern>
yea, superh's insn size is 16 bits only
<cr1901_modern>
IIRC
<whitequark>
freemint: exactly
<whitequark>
risc-v benefits from llvm, for one
<freemint>
SuperH's compiler might have goten a bit dusty but it works well on GCC
<whitequark>
although i'm not sure if the risc-v backend is any good
<freemint>
*using gcc
<Morn_>
i think gcc's risc-v port is better than llvm
<whitequark>
yeah, this is fairly common
<sorear>
the llvm backend has improved a lot and is actually usable
<sorear>
I think it still has some arbitrary limitations, like needing 3 instructions instead of 2 for PIE global access
<mithro>
The llvm backend is being more actively funded now
<whitequark>
was there some issue with linker relaxation too?
<cr1901_modern>
the algorithm is/was O^2
<cr1901_modern>
(sorear, could you correct me on this?)
<freemint>
also 1/4 of J-Cores address space i still free for co-processors, i doubt RISC-Vc has much head room since it can't conflict with with the 32 bit instructions.
<freemint>
I have to take a look though
<Morn_>
with 32 bit instructions you get a lot more space for custom op codes
<freemint>
True nobody denies that
<whitequark>
i'm not sure if coprocessors are a good idea, it never seems to work out
<freemint>
Well floating point seems to work
<Morn_>
yeah if you indeed need 16 bit custom risc-v opcodes then the existing instructions limit you greatly
<whitequark>
FP in risc-v is native
<Morn_>
the term "coprocessor" is not that clearly defined
Jybz has quit [Quit: Konversation terminated!]
<whitequark>
both a part of ISA and integrated with the core
<whitequark>
strapping an FP unit to the side of a core usually doesn't end well
<sorear>
lld doesn’t do the relaxation at all
<daveshah>
Reminds me of a cursèd 6502-based vaguely-NES-inspired SoC (VT168) that I played around with emulating a while ago
<sorear>
1/8 of riscv’s 32-bit encoding space is just fmas
<daveshah>
Multiply and divide where a "coprocessor" sitting in the address space
<whitequark>
i've seen those
<mithro>
freemint: If your happy to use ISE / Vivado you can use VHDL+Verilog right now
<daveshah>
Except divide was actually broken iirc
<freemint>
Does every Risc-V chip have to have 32 int and 32 float registers?
<mwk>
freemint: 32 int yes, 32 float optionally
<daveshah>
No, rv32e is a spec for 16 int registers
<mwk>
unless you want the embed... yes
<daveshah>
not sure how mature it is though
<freemint>
I am currently only reading VHDL code since my first step is port the RTOS.
<daveshah>
Not sure which supports a better subset of VHDL right now
<daveshah>
(this is also a nice example of the Yosys plugin interface)
<whitequark>
oh yeah, this reminds me of another reason VHDL doesn't get much traction in FOSS
<whitequark>
it's because all 2 people who know and use Ada do something else
<freemint>
ouch that hurts
<whitequark>
also no Ada programmer I know likes gnat
<freemint>
but it sounds true
<freemint>
Thank you for the feedback on my battle plan. whitequark and everyone else
emeb has joined ##openfpga
<oeuf>
whitequark: I'm unsurprised that none would like gnat, but how many do you know
<whitequark>
like... two?
<oeuf>
impressive
<oeuf>
who's the other one
<whitequark>
uh, we haven't talked in like five years
<oeuf>
lɒl
<whitequark>
and i don't think he exists on english internet
<oeuf>
but thanks to Ada 2005 he can write using Cyrl identifiers now
<oeuf>
whose case folding is defined in the documents mentioned in the note in section 1 of ISO 10646
<oeuf>
ah here's the exact wording
<oeuf>
> When this International Standard mentions the conversion of some character or sequence of characters to upper case, it means the character or sequence of characters obtained by using locale-independent full case folding, as defined by documents referenced in the note in section 1 of ISO/IEC 10646:2003.
<oeuf>
"documents referenced in the note in section 1 of ISO/IEC 10646:2003" :D
mumptai has quit [Remote host closed the connection]
<whitequark>
lol
_whitelogger has joined ##openfpga
_whitelogger_ has joined ##openfpga
_whitelogger_ has joined ##openfpga
_whitelogger__ has joined ##openfpga
_whitelogger__ has joined ##openfpga
_whitelogger__ has joined ##openfpga
_whitelogger___ has joined ##openfpga
_whitelogger___ has joined ##openfpga
_whitelogger___ has joined ##openfpga
_whitelogger___ has joined ##openfpga
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
genii has quit [Quit: Dammit Mitch]
carl0s has quit [Remote host closed the connection]