<ysionneau>
ah good idea to only build or1k target
<whitequark>
llvmpy readme seems to suggest it wants a static build
<whitequark>
i think that's a silly idea
<whitequark>
at least if you're working on your fork of llvm, as we do
<ysionneau>
afaik we don't use llvmpy anymore we just llvmlite
<ysionneau>
which presents kind of the same interface
<whitequark>
llvmlite i mean
<GitHub193>
[misoc] enjoy-digital pushed 5 new commits to master: http://git.io/h17K
<GitHub193>
misoc/master de2f1c3 Florent Kermarrec: sdram: create module.py to define SDRAM modules and use it on de0nano/ppro targets
<GitHub193>
misoc/master 6e4b7c6 Florent Kermarrec: sdram: split sdram_timing in sdram_timing_settings/sdram_controller_settings...
<GitHub193>
misoc/master fd2f8d4 Florent Kermarrec: sdram: define MT46V32M16 and use it on m1/mixxeo
<GitHub173>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/h1Fe
<GitHub173>
misoc/master 1c0e306 Florent Kermarrec: targets/kc705: rename sdram_module to sdram_modules to reflect that we have 8 modules sharing the same characteristics
<GitHub167>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/h1Fp
<GitHub167>
misoc/master 711540e Florent Kermarrec: targets/mlabs_video: rename sdram_module to sdram_modules to reflect that we have 2 modules sharing the same characteristics
_florent_ has joined #m-labs
<GitHub40>
[migen] enjoy-digital pushed 4 new commits to master: http://git.io/h1hQ
<GitHub70>
[misoc] enjoy-digital pushed 2 new commits to master: http://git.io/hMMp
<GitHub70>
misoc/master c60d995 Florent Kermarrec: sdram/module: add tREFI uniformization to TODO
<GitHub70>
misoc/master b75e4b2 Florent Kermarrec: software/bios/memtest: add data bus test (0xAAAAAAAA, 0x55555555) on a small portion of the test zone....
<GitHub22>
[migen] enjoy-digital pushed 1 new commit to master: http://git.io/hMDf
<GitHub22>
migen/master 7440ccd Florent Kermarrec: mibuild/xilinx/programmer: add iMPACT programmer (for sb: I need it in Windows for now since I was not able to get XC3SPROG working)
<whitequark>
btw, why do we build both or1k-clang and or1k-gcc?
<whitequark>
that seems... extremely redundant
<sb0>
or1k-clang can't compile the misoc bios correctly right now
<whitequark>
oh
<whitequark>
(personally i would also set binutils on fire and use lld instead, but that's some more work)
<sb0>
yeah
<sb0>
I looked at doing things like that for lm32 a while ago, but it's a pita
<whitequark>
lld recently gained elf and linkerscript support
<whitequark>
so it should be mostly ready
<whitequark>
eh, it's fine
<whitequark>
i'm wondering why migen generates verilog and not rtl
<whitequark>
rtl seems more straightforward
<whitequark>
for simulation?
<sb0>
what's "rtl"?
<whitequark>
register transfer level
<sb0>
yes, but what do you mean by that?
<whitequark>
well... currently you take logic, convert it to verilog, feed it to a synthesis tool, which converts it to rtl, then feed it to PAR
<whitequark>
why not cut out verilog?
<whitequark>
you still need optimization and expansions on rtl level, which could be done by yosys or something
<whitequark>
probably wouldn't change a design that works, but i'm wondering why is it done this way
<whitequark>
though i like the idea of replacing more of the toolchain with a single FOSS tool, producing repeatable results even for different FPGA vendors
<whitequark>
$ ./xsetup
<whitequark>
./bin/lin64/xsetup: line 21: 32454 Segmentation fault ${XLNX_DIR_NAME}/_xsetup "$@"
<whitequark>
good job xilinx. good job.
<sb0>
how exactly do you define "rtl"?
<whitequark>
netlists
<GitHub67>
[misoc] enjoy-digital pushed 2 new commits to master: http://git.io/hMN0
<GitHub67>
misoc/master c55199d Florent Kermarrec: misoclib/soc: add _integrated_ to cpu options to avoid confusion
<GitHub67>
misoc/master 9bc71f3 Florent Kermarrec: rename sdram mapping to main_ram
<whitequark>
i thought there is a common format?
<sb0>
no, there isn't
<whitequark>
oh.
<whitequark>
ok, that explains.
<sb0>
there's EDIF which is semi-standard, but the component of the netlist are FPGA-dependent
<sb0>
*components
<sb0>
it's basically a graph of instances of LUTx, FD, etc.
<sb0>
(on Xilinx)
<sb0>
if your migen design is only made of such instance, migen does support EDIF output
<whitequark>
right. what do other vendors do? i thought the same
<sb0>
the problem is converting the higher level logic description to those instances
<sb0>
which is what yosys does (with the handicap of all the verilog corner cases)
<whitequark>
*nod*
<whitequark>
well, i mean, yosys uses netlists as an IR
<sb0>
other vendors have different components in their netlists.
<whitequark>
you could output yosys netlists with high-level logic blocks. the kind it would emit itself just after the frontend
<whitequark>
and then let yosys lower it down to a vendor-specific netlist.
<whitequark>
i think that's the optimal pipeline
<sb0>
and there are different flavors of flip flops for example: with/without a reset port, can the FF reset to one instead of zero, with/without a clock-enable pin
<sb0>
synthesizers need to know about such things
<sb0>
carry chains are another rabbit hole
<sb0>
yosys synthesis doesn't work very well. designs are larger and slower than with xst.
<whitequark>
i see
<whitequark>
that's a pity
<sb0>
so for real-world projects, we do need to support xst
<sb0>
additionally, we want to support lattice and altera fpgas, too
<sb0>
and verilog is the common language that all synthesis tools will accept
<sb0>
an interesting thing to do would be direct migen synthesis
<sb0>
transform the fhdl to turn the logic into instances, then export to edif (and you can still export to verilog for debug)
<whitequark>
that looks like you would be replicating a good part of yosys
<whitequark>
optimization
<sb0>
yes
<whitequark>
i would say improving yosys is a better idea then
<whitequark>
especially seeing as python is poorly suited to the kind of problems you encounter while optimizing large netlists
<GitHub145>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/hDUh
<GitHub145>
misoc/master 70469e1 Florent Kermarrec: sdram: simplify the way we pass settings to controller and rename ramcon_type to sdram_controller_type (more explicit)
<sb0>
for speed/memory maybe, for the all the rest it's a lot better than C++ ...
<whitequark>
dunno. i personally don't care whether it's python or c++. they both have annoyingly simplistic and inexpressive type systems
<whitequark>
something with ADTs and parametric polymorphism would be an improvement :p
<sb0>
_florent_, urgh, no
<_florent_>
what?
<sb0>
the lasmicon-specific ControllerSettings must be put with lasmicon
<sb0>
problems with this patch are: 1) the controller settings are spread over many modules in the code 2) the grouping in the namedtuple is not used consistently 3) the type string is duplicated in two places (self.sdram_controller_type and self.sdram_controller_settings.type)
<sb0>
and to make #1 worse, some settings are specific to one controller
<sb0>
what about this:
<sb0>
in minicon, define an empty MiniconSettings class/namedtuple
<sb0>
in lasmicon, define a LasmiconSettings class/namedtuple containing those parameters you have right now
<sb0>
then the user creates the correct *Settings class and passes it to SDRAMSoC
<sb0>
you can import both MiniconSettings and LasmiconSettings in mem/sdram/__init__.py to simplify the imports for the user
<sb0>
but their detailed definition must lie with each controller
<_florent_>
OK I change that
<sb0>
you can use isinstance() to determine which controller to use
<sb0>
(on the *Settings)
<_florent_>
yes and for the settings, why don't we create class with default parameters (since we use the default settings on all controller for now)
<sb0>
yes, it's a good idea to have defaults in LasmiconSettings
<_florent_>
OK
<sb0>
I don't know if you can do it with namedtuple
<_florent_>
can I keep with_memtest and with_bandwidth as SDRAMSoC parameters?
<_florent_>
to be able to change that in the make.py command line
<sb0>
yes
<sb0>
with_memtest doesn't go into the controllers, does it?
<sb0>
it just adds one core to SDRAMSoC
<_florent_>
sb0> you can use isinstance() to determine which controller to use : not sure if I want to keep the possibility to configure sdram_controller_type from the command line
<sb0>
hmm, not sure how important that feature is
<sb0>
otherwise you can always use eval()
<sb0>
in fact, using eval() will solve the problem of with_bandwidth, which is also lasmicon-specific
<_florent_>
I don't use it, I can remove that if you want
<sb0>
i'd advocate keeping it, improving it so that arguments are sent through eval(), and putting with_bandwidth into LasmiconSettings
<_florent_>
can you describe a bit your eval() method?
<sb0>
it'll parse things like "LasmiconSettings(with_bandwidth=True)" from the command line, if you give it the right dicts
<_florent_>
ah OK :)
<sb0>
alternatively, if we want to keep simpler strings
<sb0>
(like it's done for eg cpu_type)
<sb0>
we can have a simple parser that would create the correct *settings based on strings like lasmicon:with_bandwidth,req_queue_size=4
<sb0>
and if sdramsoc sees a string in sdram_controller_settings, it calls the parser
<_florent_>
OK I'll add the parser after if needed
<sb0>
but we might be overthinking things right now :)
<sb0>
I'm not really changing sdram parameters from the command line...
<sb0>
cpu yes
<sb0>
all the other settings? almost never
<sb0>
and where do we stop? if we can configure the sdram controller request queue size from the command line, why not the rtio output fifos depths on a per-channel basis?
<_florent_>
agree
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
sb0 has quit [Remote host closed the connection]
sb0 has joined #m-labs
<GitHub178>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/hDzP
<GitHub178>
misoc/master 30c2521 Florent Kermarrec: sdram: pass sdram_controller_settings to SDRAMSoC
rjo_ has joined #m-labs
<rjo_>
sb0: the pipistrello port works afaict. i did not test it against dds. but i don't see trouble there since the hardware is the same.
<rjo_>
then again. eating cake dough before it's baked leaves a smaller cake and can give you salmonella...
<rjo_>
that work would be better spent on more pressing issues.
<rjo_>
less glamorous ones certainly.
<GitHub176>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/hDVE
<GitHub176>
artiq/master 494c670 Florent Kermarrec: targets/artiq_ppro: use new sdram_controller_settings parameter
<GitHub88>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/hDzP
<GitHub88>
misoc/master 30c2521 Florent Kermarrec: sdram: pass sdram_controller_settings to SDRAMSoC