<tpb>
Title: Instantiate VHDL and Verilog IP — SpinalHDL documentation (at spinalhdl.github.io)
<gurki>
but how would i actually do this?
<gurki>
bonus points if i can simulate the entire core in such a way that i can feed c code implementing this boxes behaviour to the simulator
<gurki>
this is a quite ... complex ... mixed signal core so i cannot provide an actual implementation for spinalhdl to convert to hdl
<gurki>
im not set on vexriscv per se, but i liked the plugin system
<gurki>
(i hope this is topical, i wasnt quite sure)
<gurki>
i do have a possible workaround for the simulation part using spike, but having everything nicely integrated is obv nicer
<tpw_rules>
do you want to do all this through litex?
<tpw_rules>
a bit confused about the part you are stuck at. doing it through litex? or hooking up a custom instruction that is not primarily based on spinalhdl?
<gurki>
my main focus is "how do i properly integrate a mixed signal core into vexriscv", i assumed that the reasonable way to do so is by using a custom instruction which i hand over as a blackbox
<gurki>
litex might be part of the solution
<tpw_rules>
why would it be an instruction and not an mmio peripheral?
<gurki>
is that wise? what this core does is (example, not what its actually doing) perform aes on a large chunk of data (ideally handed over via a memory adress) and return some result; but it would be nice to be able to just do "aes()" using an asm intrinsic from plain c
<tpw_rules>
and that can't be a store instruction into a peripheral?
<gurki>
i am looking for good ideas, thats why i asked. maybe your approach -is- better
<tpw_rules>
it seems a bit silly to just stall the core for a bunch of cycles to crunch on some data. i would heavily encourage an mmio approach i think
<tpw_rules>
that's not very RISC :P
<tpw_rules>
a mungeBlock you call in a loop maybe
<tpw_rules>
or swapStatus. i don't know much at all about the vexriscv plugin system though. just the litex guts
<tpw_rules>
they do have an iterative multiplication example which would be interesting to look at
<gurki>
i was just about to ask for an example to look at :3
<tpw_rules>
(for a plugin)
<tpw_rules>
i don't think vexriscv conceptualizes mmio much. that is where you would step out to an SoC builder like litex
<gurki>
how much additional pain do i need to expect for setting up a simulation and getting synthesizable hdl?
<gurki>
(obv "not much" for sb who is already familiar ...)
<tpw_rules>
i don't know. that stuff using vexriscv through litex is very easy even for a noob. but it's pretty abstracte
<tpw_rules>
d
<gurki>
do i - at some point - get an interface to shove random c to the/a simulator?
<gurki>
it is probably using verilator, so i could do crappy function pointer yada, but id rather not
<tpw_rules>
it does use verilator somehow. i don't know the details about that. i'm not a heavy litex user
<tpw_rules>
but litex's wrapper around vexriscv is pretty simple. it just dumps specific verilog to disk at compile time of the vexriscv litex plugin and then reads those later
<tpw_rules>
so if you are more comfortable in verilog and want to put the things together yourself you can just use vexriscv's scala generators yourself
<tpw_rules>
someone else might be able to weigh in better on actually interfacing with simulation
<gurki>
well i will have to touch the verilog for the synthesis part, so its handy that i can do whatever to it and still verify the results
<gurki>
im still not sure whether i will ever have a verilog simulation model for that core since its. uh. "complicated" to do
<gurki>
characterizing larger mixed signal cores isnt exactly fun
<tpw_rules>
how do you plan to synthesize it
<gurki>
hence the need for "can i just plug in the c simulation model"
<gurki>
dc_shell to asic
<gurki>
it will happily take blackboxes
<gurki>
i will need to provide _some_ timing information, but that is yet another beast to deal with
<tpw_rules>
ah so you are not targeting an FPGA. that's what you mean by mixed signal, real analog. i sort of thought you meant like DSP
<gurki>
ah. sorry for being vague
<gurki>
yes, i have pure analog parts in there
<tpw_rules>
then yeah it sounds like you are stepping well outside of both my and litex's comfort zone. i think dumping a verilog core from vexriscv and using a flow you are familiar with might be best. that is sort of orthogonal to the question of whether to use the plugin system but unless it's one of those funky new analog neural matrix multipliers it really doesn't make sense as an instruction imo
FabM has quit [Ping timeout: 248 seconds]
Advant has joined #litex
<Advant>
I'm trying to setup f4pga on macOS x64, and it's wanting certain pre-reqs that aren't available on https://conda.anaconda.org/litex-hub/osx-64, like prjxray.. is there a work around for setting this up?