<sb0>
when you want to show off some python, you use myhdl. when there is work to do, you use migen.
<sb0>
seriously though
<sb0>
myhdl does a python syntax to verilog/vhdl conversion, and interfaces to a simulator so you can write your test bench in python
<mithro>
I haven't had much chance to look into either
<sb0>
so the advantages of myhdl are 1) better syntax than verilog/vhdl (and some mess like verilog sign extension cleaned up) 2) much better test benches
<mithro>
sb0: both those sound good :P
<mithro>
sb0: what does migen give you?
<sb0>
with migen, you are writing a python program that is run and generates the design. that lets you automate a _lot_ more things than myhdl (and the result is always synthesizable)
<sb0>
there are also syntax hacks, and similar cleanups that myhdl does, so the migen syntax is also better than verilog/vhdl
<sb0>
and migen also has a simulator interface that allows full Python testbenches
<mithro>
okay, so migen is just a straight hdl generator?
<sb0>
myhdl is
<sb0>
for synthesis, it merely parses the python code and outputs it with a different syntax (verilog/vhdl)
<sb0>
one simple thing that migen can do and myhdl can't, is dynamic generation of a bus arbiter given a list of initiator interfaces
<sb0>
(hdmi on mixxeo) intended use is 4x HDMI inputs 1x DVI/VGA output
<mithro>
sb0: I was trying to figure out your 4 HDMI ports on the mixxeo - are they all inputs?
<sb0>
I don't remember if the HDMI can also be used as outputs and with how much PCB rework
<sb0>
yes
<sb0>
there's only one catch, you can only have two simultaneously sampling due to the limited number of PLLs in the LX45
<sb0>
switching them is OK
<mithro>
sb0: yeah, I was just about to ask about how you manage with the limited PLL resources
<sb0>
or you can use a footprint compatible FPGA with more PLLs
<sb0>
iirc the lx75 works
<mithro>
once you go bigger then the LX45, you need to pay for the tools IIRC :/
<sb0>
it's not hard to get them for free..
<sb0>
so you can get kicad boards routed in India?
<mithro>
sb0: ahh I use you used the CSG484 footprint, we are using the CSG324 footprint with some "custom hacks" to allow both LX and LX-T devices loaded
<sb0>
fgg484
<mithro>
sb0: I'm working with a group in india who do open source hardware full time - http://numato.com/
<mithro>
I've been doing the high level design and review work, they have been doing the work of actually generating the schematic and PCB
<mithro>
sb0: I see that you aren't using any buffers / levelers on the HDMI inputs - how do you find the signal receive quality? I assume your using shortish cables?
<sb0>
tried with ~2m cables
<sb0>
why should external buffers be better than the buffers built into the FPGA?
<sb0>
some devboards have them but AFAICT only for marketing reasons
<sb0>
wow they still sell spartan 3a boards
<mithro>
sb0: well they are not used for buffering - more releveling - IE making sure peak-to-peak voltage swing is large enough. When your cable is 30m, they make the difference :)
<mithro>
sb0: I'm impressed that you did your board with 4 layers
<mithro>
oh wait
<sb0>
6
<mithro>
I just can't count :P
<mithro>
6 is still pretty good
<mithro>
sb0: btw - where in the world are you located?
<sb0>
and the FPGA would not detect the smaller voltage swing?
<sb0>
hong kong
<sb0>
you can perhaps do with 4...
<sb0>
if I were to do this board again I'd use a 7-series and ddr3
<sb0>
7-series finally has acceptable SERDES and IODELAYs, as opposed to disasterous ones in S6
<sb0>
and they _will_ fail on you if you do HDMI
<mithro>
sb0: the Zynq chip seems pretty awesome - I have a couple of the Zybo boards to play with
<sb0>
is the smallest zynq cheaper than the smallest artix?
<mithro>
sb0: so, I saw on the list something about memory testing infrastructure?
<sb0>
I'd rather not use this proprietary ARM stuff
<sb0>
lm32 is fast enough to control hdmi dma...
<mithro>
sb0: probably not - the Zynq has equivalent to an Atrix on the same chip as dual ARM hard core
<mithro>
sourcing small quantities of the Zynq chips seems pretty hard though
<sb0>
mithro, do you already have a s6 board with hdmi?
<sb0>
you should try to run the mixxeo/misoc code on that
<mithro>
sb0: yes, I have quite a few of the Digilent Atlys boards
<mithro>
sb0: and a couple of prototypes of our board
<sb0>
hpdmc_ddr32 is the old (milkymist one) verilog ddr sdram controller.
<mithro>
sb0: so, where is the new one? :P
<sb0>
the memtest core is a core that writes high speed LFSR data to the SDRAM, and then reads it back and compare, and is meant to test the new lasmicon controller
<mithro>
sb0: I'm trying to figure out the best way to get to the stage of being able to run the misoc on my boards - I think starting with copying https://github.com/m-labs/misoc/blob/master/targets/mlabs_video.py to digilent_atlys.py and removing the minimac+dvi/vga out stuff - and replacing the flash stuff with the SPI stuff from ppro.py
<sb0>
the first step would be to get a minimal SoC running
<sb0>
ppro does XIP of the BIOS from the serial flash, and this stuff tends to act up, so I recommend you run the BIOS from BRAM first
<mithro>
okay
<sb0>
all you need to do is remove the flash stuff, derive the SoC class from IntegratedBIOS, and call IntegratedBIOS.__init__
<mithro>
sb0: do you have a "minimal-customize-me.py" target hidden somewhere :P
<sb0>
no... because all boards have different clocks and things like that
<sb0>
but the ppro is close enough
<sb0>
you should also derive from GenSoC instead of SDRAMSoC, until you start implementing the SDRAM
<mithro>
sb0: the clocking infrastructure on the Atlys is closer to the mlabs_video.py ? We have a 50MHz input clock
<sb0>
depends what you want to do...
<sb0>
if you have no need for multiplied/phase aligned clocks etc. you can
<sb0>
simply have a IBUFG/IBUFGDS driving cd_sys.clk
<mithro>
sb0: will migen work inside a virtualenv?
<sb0>
you can simply use PYTHONPATH and not install it
<mithro>
ahh, it's pure python, \o/
<mithro>
just following your README now, getting binutils
<mithro>
sb0: I was sure I asked you, but I can't find it in the scroll back now - where in the world are you located?
<sb0>
Hong Kong
<sb0>
and you?
<mithro>
Sydney, Australia
<mithro>
sb0: it sounds like you might actually understand the IODELAYs inside a spartan 6?
<sb0>
yes, and I don't like what I understand
<sb0>
xilinx completely replaced them with a new design in the 7-series, a wise decision
<mithro>
sb0: if I understand correctly, they can be used to delay incoming IO values by a given amount - with the delay being somewhere around ~16ps per tap on a grade -2 device
<sb0>
you forgot some important details here: they delay incoming IO signals by an *uncalibrated* amount with *large PVT variations*, and the IDELAY *fails* should the delay exceed one bit time
<sb0>
(and I mean the delay after the PVT variation. so you quite don't really know when you are safe...)
<mithro>
sb0: does the calibration feature help at all?
<sb0>
the programming interface of the IDELAY is another fuckup (and something they fixed in the 7-series). when you use that calibration feature that places the delay at a value between two transitions (at that given point in time - voltage and temperature can mess with it later), you can't know the number of taps, all you can do is increase/decrease them without knowing where you are
<mithro>
sb0: and are the *large PVT variations* individual or systematic? IE each IODELAY is affected differently by the T/V
<mithro>
sb0: yeah - that seemed pretty retarded
<sb0>
of course, when you increase/decrease them and hit the first or last tap (or exceed a post-PVT delay of one bit time), you get unexpected behaviour
<mithro>
sb0: what type of variation are people seeing in the wild?
<sb0>
I don't have hard numbers... but the datasheet numbers are pretty scary
<mithro>
sb0: do you know if IODELAY objects can be used between a BUFPLL and the input to the SERDES?
<sb0>
you want to delay the BUFPLL output before you connect it to the SERDES clock?
<sb0>
no, this will fail
<sb0>
and changing the PLL phase will fail too, the SERDES expects fabric clock/bufpll clock phase alignment
<mithro>
sb0: I'm looking for a way to accurately phase offset a bunch of ISERDES (this might actually be impossible). I've been looking at if I could use IODELAY to do this
<sb0>
IODELAY cannot be routed to anything else than IOBs
<sb0>
so no
<sb0>
also, most SERDES clocking scheme that are not in xilinx application notes will at a minimum tickle a number of pesky ISE bugs and often fail completely
<mithro>
sb0: well, delaying the IO into the SERDES is equivalent to delaying the capture clock, no?
<sb0>
from an external perspective yes
<sb0>
and this way of doing is the xilinx-recommended one
<mithro>
sb0: sounds like I'm best of using a series 7 device if I want to make those delays accurate though?
<sb0>
yeah, the 7-series iodelays (which look like they are based on the virtex) are much better than the s6 ones
<sb0>
yeah. networkx is something we should get rid of at some point.
<mithro>
sb0: so the build system appears to be using just basic "as" rather than "lm32-elf-as" - just trying to figure out why....
<sb0>
are you building it with make.py?
<mithro>
yes
<sb0>
the prefix is variable, as misoc supports both lm32 and openrisc
<sb0>
there must be something wrong with that part of the code..
<sb0>
it's the first time I hear of it breaking though
<mithro>
sb0: it's probably because I didn't install gcc/binutils to /usr/local
<mithro>
sb0: recompiling my gcc with "--with-as" pointing to the right location fixed that issue
<mithro>
sb0: pull request the right way to send a minor patch?
fengling has joined #m-labs
<mithro>
well, built the bios and bitstream successfully!
<sb0>
mithro, don't use pull requests, send your patch to the mailing list instead
<mithro>
sb0: just adding a custom platform to migen/mibuild/platforms - is that the right way?
<sb0>
for a new board? yes
<sb0>
but please have a look at the other platforms and try to keep signal names consistent
<mithro>
sb0: yes, starting by copying the mixxeo file and customizing
<mithro>
sb0: this stuff is pretty awesome so far, you guys have done excellent work!
_florent_ has joined #m-labs
<_florent_>
hi
<_florent_>
sb0: "With 3-state DCI I/O standards, the DCI termination legs turn off whenever the driver is
<_florent_>
active."
<_florent_>
"The IOBUF_DCIEN primitive further allows the termination legs to be disabled
<_florent_>
whenever the DCITERMDISABLE signal is asserted High"
<_florent_>
"These features can be combined
<_florent_>
to reduce power whenever the input is idle for a period of time."
<_florent_>
so yes DCI is disabled automatically when we drive the output
<_florent_>
since we don't care of power for now, it should be ok with only IOBUF
xiangfu has joined #m-labs
<mithro>
sb0: would you happen to still be about?
<sb0>
yes
<mithro>
sb0: so, I have a migen/mibuild/platforms/digilent_atlys.py which should be pretty good - is there a way to test it now? (I also have a misoc/targets/digilent_atlys.py - but I think that needs more work)
<mithro>
are things in migen/examples/ useful for that?
<sb0>
what do you mean by 'test'?
<sb0>
well, no, that's very dependent on the peripherals you have on your board
<mithro>
sb0: so - only way to test my platform file works is to use it inside a misoc?
<sb0>
what exactly do you want to test?
<sb0>
you can also make migen-only (without misoc) designs
<sb0>
but no, we don't have migen test fixtures for whatever chip is on the devboard du jour
<mithro>
sb0: don't have a migen which just flashes a single LED or something?
<sb0>
it'd be a lot of work to make them, and not very interesting...
<ysionneau>
so yes you can try first the tutorial, it's always good to start with that
<ysionneau>
but as sb0 said it will not test much of your platform file
<mithro>
ysionneau: it proves I don't have a syntax error in my platform file :P
<ysionneau>
yes, well it depends if you have conditional paths :p
<ysionneau>
but in platform files I guess no
<mithro>
migen-tutorial all works
<ysionneau>
great!
<ysionneau>
have you tried to just have a look at the verilog output?
<ysionneau>
instead of directly generating bit file
<ysionneau>
just out of curiosity
<mithro>
ysionneau: yeah - I looked at the output from the examples when I first checkout the code
<ysionneau>
ok
<mithro>
ysionneau: I've also successfully built the misoc stuff for the mixxeo (but obviously can't test flashing that...)
<ysionneau>
ok so your setup is all ready
<mithro>
turns out that the Atlys clock is 100MHz not 50MHz - guess I will have to instantiate a PLL
fengling has quit [Quit: WeeChat 1.0]
sh4rm4 has quit [Ping timeout: 260 seconds]
sh4rm4 has joined #m-labs
<mithro>
okay, I've run into the problem with the DDR2 clock - with the MIG we use a DIFF_STL188_II clock to the DDR - however in your system it seems to be two single ended pins?
<mithro>
it looks closer to what happens for the DDR clock in the kc705.py system
<mithro>
sb0: or is this the 4X thing you where talking about earlier?
<sb0>
no. what I meant is that the current PHY can only send 2 SDRAM commands per FPGA clock. if you want to use DDR2 at full speed, you should multiply the clock another time and make that 4.
<mithro>
sb0: so, I'm not sure what the correct way to proceed with the DIFF clock issue
<mithro>
sb0: is it as simple as just instantiating a OBUFDS using clk2_off ?
<mithro>
is it just a legacy reason that there is a mxcrg.v for the mixxeo / m1 versus doing everything in Python for the ppro?
<mithro>
blinkie works!
<ysionneau>
\o/
<ysionneau>
congratz
<mithro>
trying a full misoc FramebufferSoC build now
<mithro>
well, the .bit builds but doesn't meet timing
<mithro>
so, after loading the .bit file misoc, what comes next? :P How do I interact / test it out?
<ysionneau>
usually your misoc runs a BIOS
<ysionneau>
you can connect via UART (usb<->uart ?)
<ysionneau>
and just type "help"
<ysionneau>
and you will be able to do a few things like reading memory, writing memory etc
<ysionneau>
I've never make DDR workd myself on a new target
<mithro>
ysionneau: in theory I have
<mithro>
ysionneau: it's probably all totally wrong though
<ysionneau>
so yes you can test your DDR2 setup by uploading the memtest via serialboot
<ysionneau>
sb0: the software doing the "Initializing SDRAM..." part, is this FPGA-chip dependant? board dependant? or does it work with all misoc ports?
<_florent_>
mithro: before running memtest, you have severals things to verify and change to use the DDR2
<_florent_>
mixxeo use a DDR not a DDR2, and you have to change the Phy's parameters
<mithro>
_florent_: done!
<mithro>
well, in theory - I'm not sure I've got the timing numbers right
<_florent_>
memtest is in fact testing the DMA
<_florent_>
before that you have to verify that the PHY is working well
<mithro>
_florent_: how does one do that?
<mithro>
_florent_: I've only used the MIG in ISE to do this before
<_florent_>
except that you only get results from phase 1 (0x10) and not phase 0
<mithro>
sdrinit shows "Memtest failed: 524288/1048576 words incorrect"
<mithro>
which looks precisely like *half* the words are incorrect
<_florent_>
yes
<_florent_>
can you provide me your target file?
<mithro>
_florent_: target file?
<ysionneau>
the file in /targets/
<ysionneau>
misoc/targets/
<_florent_>
your top in fact
kilae has joined #m-labs
<_florent_>
just to see the DDR2's parameters and how you instanciate the PHY
<mithro>
_florent_: sure - just let me check that I haven't stuffed up my Geom/Timing settings
kilae_ has joined #m-labs
kilae has quit [Ping timeout: 245 seconds]
<mithro>
_florent_: I don't quite understand the correct values to use for req_queue_size=8, read_time=32 and write_time=16 given to the lasmicon.TimingSettings
<_florent_>
you don't need to change that
<_florent_>
req_queue_size if the size of the cmd fifo
<_florent_>
read_time and write_time define the time to alternate between read and write IIRC
<mithro>
_florent_: just uploading my target information now
<mithro>
It's a bit confusing as originally this board had the MT47H64M16HR-25E part, but it was then replaced with the MIRA P3R1GE4JGF - yet the data sheet says it's been replaced with the P3R1GE*3*JGF
<_florent_>
and if you read directly on the SDRAM? :) (but I think they are all compatible)
<mithro>
_florent_: reading directly from the chip I find MIRA P3R1GE4JGF
<mithro>
_florent_: they have different bank/col/row structure from what I can see
<mithro>
sdrrd still returns 1011121310111213
<_florent_>
we have a board working with DDR2, you can try to use the same settings on the PHY: