<sb0>
litescope should stop abusing misoc.integration
* cr1901_modern
shrugs. Was probably a good idea at the time
<sb0>
if there's no CPU, no CSR bus, etc. then connect the cores in another way
<cr1901_modern>
Not everyone wants to write their own register bank functions when CSR works fine.
<sb0>
you can use the CSR bank generator without SoCCore and friends
<cr1901_modern>
Then does that mean you would now accept a patch to CSR for little endian support (part 2 of what was on my mind)?
<sb0>
what do you need that for?
<cr1901_modern>
I don't; I wrote my own register bank fcns. However, if CSR supported little endian, I would've used it for this project: https://github.com/cr1901/n6502fpga
<sb0>
isn't the 6502 8-bit?
<GitHub126>
[migen] sbourdeauducq pushed 1 new commit to new: http://git.io/vcYsJ
<GitHub126>
migen/new 913558a Sebastien Bourdeauducq: build: stop at the first failed Quartus command
<cr1901_modern>
... can you please stop making me look like an idiot? T_T Yes. >>
<sb0>
so why is endianness relevant?
<cr1901_modern>
It only matters for certain addressing modes and pushing/popping the stack
<cr1901_modern>
you would never use said addressing modes for I/O, hence my idiocy
<sb0>
are you pushing/popping the stack into the CSR space?
<cr1901_modern>
I made a mistake XD
travis-ci has joined #m-labs
<travis-ci>
m-labs/migen#116 (new - 913558a : Sebastien Bourdeauducq): The build is still failing.
<cr1901_modern>
sb0: I do remember use case for I had little endian. I wanted to create a custom peripheral for a little endian 16-bit processor; an ASIC attached to my dev board's I/O, since the soft cores aren't all that good.
<cr1901_modern>
The goal was to create a SBC with CPLDs implementing peripherals. I suppose that's not really a common use case however, and I'm not currently working on this.
rohitksingh has joined #m-labs
Gurty has joined #m-labs
fengling__ has quit [Ping timeout: 245 seconds]
fengling__ has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
antgreen has quit [Remote host closed the connection]
<sb0>
cr1901_modern, is that asic going to be better than lm32?
antgreen` has joined #m-labs
<GitHub144>
[misoc] sbourdeauducq pushed 3 new commits to new: http://git.io/vcY7D
<GitHub144>
misoc/new c36029f Sebastien Bourdeauducq: command line options support, CSR CSV, all targets building
<cr1901_modern>
sb0: Not for any use cases *you* would possibly need.
<cr1901_modern>
I love FPGAs- although in the past I've had love-hate relationship with them. My current main gripe with them is that it is not exceptionally easy to protoype PCBs with them for a custom design, whereas ASICs (especially DIPs) are easier.
antgreen` has quit [Ping timeout: 256 seconds]
antgreen` has joined #m-labs
antgreen` is now known as antgreen
<_florent_>
sb0: sorry, I'm busy with others things and not very reactive
<_florent_>
I seem to have some specific needs for misoc that are not shared with others so I'm considering using my own directory for designs that need a specific integration and keep using migen for all my designs and misoc when possible.
<_florent_>
So I you think some parts of the actual code are not relevant for you, feel free to remove and simplify.
ylamarre has joined #m-labs
<sb0>
_florent_, yeah, I guess you could import the relevant modules from misoc; making it a proper python package should facilitate that
<sb0>
_florent_, the plan would be: the misoc integration/build system assumes a soft CPU based design with WB and CSR buses; projects that don't fit in this scheme can still use misoc by importing what they need and hooking it up themselves
<_florent_>
yes that seems fine, and I'll recreate specific integration files on my side
<_florent_>
same for programmers that you don't want to support
<_florent_>
I can have a repo for all this specific stuff.
<sb0>
well, i'd recommend putting time into getting openocd to work rather than into interfacing $PROPRIETARY_CRIPPLEWARE with migen ...
<_florent_>
Yes I'm planning testing it and using it if working correctly
terpstra has quit [Read error: Connection reset by peer]
<sb0>
_florent_, what are you using the endpoint parameters for?
<sb0>
_florent_, also, is data ever valid when eop=1 or sop=1?
<_florent_>
sb0: parameters are useful when you a module need to do some adaptation on the payload (ex Converter) and you don't want the parameters to be modified
<_florent_>
yes, data is supposed to be valid when sop=1 and eop=1
<sb0>
so you send the first/last data element of the packet along with sop/eop?
<_florent_>
some customer's designs + liteeth + litesata IIRC
<sb0>
the fifo implementation is pretty bad
<_florent_>
yes (I added a comment on that IIRC)
<_florent_>
if you don't want theses params you can remove it
<_florent_>
I'll add it to my specific repo
<_florent_>
or use another solution if you find one more convenient
<sb0>
it's also quite ad-hoc. what if about sub-packets, and sub-sub-packets?
<sb0>
does the liteeth mini in misoc require those?
<sb0>
it doesn't, right?
<_florent_>
no
<_florent_>
no (for params)
<_florent_>
yes for packets
<_florent_>
so I think you can remove params support if you don't need it
<sb0>
also, they can always be replaced with a second endpoint afaict
<sb0>
another thing I wonder about is whether keeping or not support for record layouts in fifos
<sb0>
it's not consistent with other cores like memories...
<_florent_>
yes, maybe we should keep things simple in migen (just raw signals support) and support records only on misoc's modules or in user specific repo
<sb0>
why do eop/sop need to be special signals, as opposed to being part of the payload layout?
<sb0>
do certain cores (converter etc.) use those to reset themselves?
<_florent_>
for converter you cannot use sop/eop in payload since you need specific adaptation on these signals