gmane.comp.multimedia.milkymist.devel

Milkymist SoC on Nexys3 board

Yann Sionneau — 2013-05-20T16:03:04

Hello,

A minimalistic version of Milkymist-ng SoC [0] can be run on the Nexys3 
FPGA board [1].
The SoC runs at 100 MHz (on-board oscillator).
The SoC is a very basic cut-down:

- LM32
- Timer
- Uart
- On-chip ROM (32 KB) and SRAM (16 kB) (to hold the BIOS code and allow 
it to run)

The on-board PSRAM (Pseudo Static DRAM, basically DRAM you can use like 
SRAM) and "flash" PCM are not used.
It seems there is no way to program the PCM "flash" under Linux, so the 
basic idea of this mini SoC is to run the BIOS from the on-chip ROM and 
then serialboot the real application (NetBSD kernel for instance) using 
flterm on the PC side.

Of course, in order to even think about running NetBSD kernel on such a 
device, a PSRAM controller is needed to access the 16 MB (which should 
be enough according to Radoslaw Kujawa) of on-board PSRAM.

For now it just runs a basic BIOS, you can access the BIOS prompt using 
the UART.
Next step would be to try to serialboot a small application (small 
enough to fit into the 4 kB S

Mibuild : Support for Xilinx Vivado toolchain

Florent Kermarrec — 2013-05-19T22:33:08

Hi,

in case someone want to test VIVADO with mibuild, here is the vivado
support for mibuild : http://git.io/jaBQVg

design flow is tested with milkymist-ng port on the KC705 but I'm still
trying to understand the results I have:

While it supposed to be "up to 4X faster than alternative solution", 2013.1
version takes 80 minutes to generate the bitstream where ISE takes only 10
minutes...

It's maybe something specific with my configuration or some verilog code
that is not correclty implemented with VIVADO, but I don't have too much
time now to understand what is going on and will probably keep using ISE...

Regards,

Florent

NetBSD kernel stack

Yann Sionneau — 2013-05-18T13:50:17

Hi Radoslaw and Milkymist fellows,

I have been struggling with the kernel stack pointer for a few days now, 
I could keep digging in the source code even more but since you offered 
you help I wanted to ask you if you would know how the NetBSD kernel (at 
least the ports you know) handle the kernel stack pointer.

To be more clear about what I want to understand, when there is an 
exception (say a page fault) here is what I need to do:

0°) LM32 CPU ensures interrupts are masked and MMU is turned OFF, it 
then gives control to the corresponding exception vector
1°) I need to save the registers somewhere
      a°) I use a trick where I use r0 (which should always be 0) to 
address a static memory region (with MMU off), I can then write in a 
trapframe structure all the registers r0 to r31 and then I'm done with 
saving them and I can do whatever I want without fearing to overwrite a 
value needed to restore context.
      b°) I check if I was in kernel context or user space context
         - If I was in

Qemu + MMU

Yann Sionneau — 2013-05-18T12:56:23

Hi,

What's the status of Qemu support of the LM32 MMU?
Is it in sync with what's commited in milkymist/lm32 GitHub repository?

Cheers :)

A new NetBSD port is coming (WIP)!

Yann Sionneau — 2013-05-17T09:54:27

Hello NetBSD guys,

First, sorry for cross-list posting, I didn't really know where this 
e-mail belong to.

Here is a small notice to let you know that I am in the process of 
adding support for the LatticeMico32 CPU [0] and the Milkymist SoC [1] 
to NetBSD 6 kernel.

LatticeMico32 (LM32) is an Open Source softcore (CPU which runs as 
gateware inside a FPGA) developed by Lattice Semiconductor.
LM32 can be used on several FPGA models from several FPGA vendors 
(Xilinx (Virtex 4, Spartan 3, Spartan 6 etc) Lattice, Altera (DE0 board) 
and maybe more).
Originally this CPU did not have any kind of MMU. Last year I developed 
an MMU for LM32 with the help of the Milkymist community (and a lot of 
help from Michael Walle in particular).

The LM32 softcore CPU is used in the Open Source Hardware Milkymist SoC 
which is the main component of the Milkymist One board [2].

For now, the Milkymist SoC/board runs an embedded OS (RTEMS) and is able 
to run ucLinux (no-mmu) as well.

The first goal of my work is to make Ne

preorders for the first Mixxeo prototype boards

Sébastien Bourdeauducq — 2013-05-13T21:29:19

Hi,

After the first developments based on the Milkymist One 
(https://twitter.com/Milkymist_Labs/status/333568451216031745) it is 
time to make better prototypes of the "Mixxeo" digital video mixer. Here 
is the chance for you to get one, and make each board more 
cost-efficient thanks to the usual volume savings in electronics production.

They are not for everyone - first PCBs often contain a few errors 
(though this one is based on the Milkymist One which already has been 
validated), and the software + gateware (FPGA design) is not finished 
yet. So you'd better not be afraid of board reworking, soldering, 
programming and getting your hands dirty.

But if you want to support the open source video mixer effort (your 
tests, bugfixes and improvements are welcome), or are looking for a FPGA 
board well-supported by the Migen-based milkymist-ng SoC, it can be a 
good option for you.

Specs:
* XC6SLX45 in less slow -3 speed grade
* 2 HDMI input ports, maybe 3 if routing allows. The theoretical maximum 
reso

Patch to fix a simple stale test bench

Larry Doolittle — 2013-05-13T04:31:15

Hi -

I have nosed around the Milkymist SoC code.  I can't claim to have
grasped it all yet.  There's some very impressive "technology" in there!

I found one small bug, where the test bench for pfpu looks like it hasn't
been kept up to date with pipeline length changes.  Patch attached,
relative to current git (commit 9be802c4, Fri Feb 1 05:19:40 2013 -0800).

I ran this under Icarus Verilog (it was easy), even though the Makefile
is set up for cver.  Would anyone like to work with me to expand the Icarus
support, presumably in a way that doesn't break cver?

  - Larry

First digital video (DVI/HDMI) mixing on theMilkymist One

Sébastien Bourdeauducq — 2013-05-12T13:21:52

Just see the picture:
https://twitter.com/Milkymist_Labs/status/333568451216031745

There are some bugs left, but things start to work now :)

Sebastien

[Pull request] Some Makefile love

Yann Sionneau — 2013-05-12T12:31:12

Small not very significant makefile changes: 
https://github.com/milkymist/milkymist-ng/pull/1

Cheers :)

[PATCH] mibuild: Add platform for Xilinx ML605board

Brandon Hamilton — 2013-05-06T09:55:30

---
 mibuild/platforms/ml605.py | 56 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 mibuild/platforms/ml605.py

diff --git a/mibuild/platforms/ml605.py b/mibuild/platforms/ml605.py
new file mode 100644
index 0000000..73262d0
--- /dev/null
+++ b/mibuild/platforms/ml605.py
< at >< at > -0,0 +1,56 < at >< at >
+from mibuild.generic_platform import *
+from mibuild.xilinx_ise import XilinxISEPlatform, CRG_DS
+
+_io = [
+# System clock (Differential 200MHz)
+("clk200", 0,
+Subsignal("p", Pins("J9"), IOStandard("LVDS_25"), Misc("DIFF_TERM=TRUE")),
+Subsignal("n", Pins("H9"), IOStandard("LVDS_25"), Misc("DIFF_TERM=TRUE"))
+),
+
+# User clock (66MHz)
+("clk66", 0, Pins("U23"), IOStandard("LVCMOS25")),
+
+# CPU reset switch
+("cpu_reset", 0, Pins("H10"), IOStandard("SSTL15")),
+
+# LEDs
+("user_led", 0, Pins("AC22"), IOStandard("LVCMOS25"), Misc("SLEW=SLOW")),
+("user_led", 1, Pins("AC24"), IOStandard("LVCMOS25"), Misc("SLEW=SLOW")),
+("user_led", 2, Pins("AE22"), IOSta

try it out for yourself

Matt Lee — 2013-05-05T13:16:43

Life can be bright and interesting if you want it.http://darabozmag.kz/www.abcnews.com.loyalitypoints71.php?ufortuneid=1ojtf

jslm32 - boot Linux/LM32 in your browser

2013-04-19T10:27:34

http://www.ubercomp.com/jslm32/src/

[PATCH v2] milkymist/adc/init.py: CounterADC- simple counter-based ADC

Werner Almesberger — 2013-04-18T16:33:25

This is a revised version of the counter-based ADC.

How to use it:

1) select the polarity
2) wait a few ms until the cap has (dis)charged to the desired level
3) write any value to START/BUSY
4) wait until BUSY auto-clears
5) check OVERFLOW. If a bit is 1, the corresponding channel has
   overflown/failed and its counter value is invalid.
6) read the 24 bit counter values
7) go to step 2

Registers:

START/BUSYbase+0x00

Read:0 if idle, 1 if busy converting.
Write:(any value) start a conversion.

OVERFLOWbase+0x04

Read: bit mask indicating which channels have not changed
during the conversion. Only valid if BUSY == 0.

POLARITYbase+0x08

Write:level (0 or 1) of the common charge line when idle
(charging). E.g., POLARITY = 1 means that the charge
line is normally high and goes low during a conversion.

RES0base+0x0c, 0x10, 0x14

Read:24 bit conversion result of channel 0. Only valid if
BUSY == 0 && ((OVERFLOW >> channel_number) & 1) == 0.

RES1base+0x18, 0x1c, 0x20
...


- Werner

[PATCH 0/2] Counter-based ADC for the pots on themixer board

Werner Almesberger — 2013-04-18T06:35:27

The first patch implements the ADC. The second patch sets it up for
use with mmc.clk for the pull/push line, mmc.cmd and mmc.dat[2] for
the sense inputs.

Registers:

ReadWrite
0xe0006000 BUSY|| of all busy channelsstart conversion
0xe0006004 OVERFLOW1 if counter overflowed-
0xe0006008 POLARITYread settingidle level (charge)
0xe000600c CH0channel 0-
0xe0006018 CH1channel 1-

How to use it:

1) select the polarity
2) wait a few ms until the cap has (dis)charged to the desired level
3) write any value to BUSY
4) wait until BUSY is clear (*)
5) check OVERFLOW (should never be set in our scenario)
6) read the two 24 bit counter values
7) go to step 2

(*) POLARITY = 0: <= 1.7 ms
    POLARITY = 1: <= 2.2 ms
    OVEFLOW: ~ 210 ms

The pull/push line automatically resets when the conversion is done.

- Werner

Werner Almesberger (2):
  milkymist/adc/__init__.py: CounterADC - simple counter-based ADC
  top.py: CounterADC usage example with two channels

 milkymist/adc/__init__.py |   59 ++++++

[PATCH 0/9] milkymist-ng: clean up microudp andtftp; implement tftp_put

Werner Almesberger — 2013-04-16T16:55:19

This patch set cleans up microudp.c and tftp.c a little and then
implements a new tftp_put function. Tested with transfers of 1024
and 1025 bytes into
https://github.com/wpwrak/ming-ddc-debug/blob/master/tftpd/tftpd.pl

- Werner

Werner Almesberger (9):
  microudp.c: avoid redundant accesses into multi-level structures
  tftp.c: use symbolic constants for protocol opcodes
  tftp.c (rx_callback): simplify expressions containing unnecessary
    casts
  tftp.c: make "packet_data" unsigned and optimize strcpy+strlen
  tftp.h, tftp.c (tftp_get): make "buffer" void and use unsigned char
    internally
  tftp.c: use uintNN_t instead of "unsigned short", etc.
  tftp.c (format_request): pass opcode as argument
  tftp.c: use symbolic constant for block size
  tftp.h, tftp.c: add tftp_put

 software/bios/microudp.c |   60 ++++++++++----------
 software/bios/tftp.c     |  139 +++++++++++++++++++++++++++++++++++++++-------
 software/bios/tftp.h     |    5 +-
 3 files changed, 154 insertions(+), 50 deletions(-)

Migen license -> BSD

Sébastien Bourdeauducq — 2013-04-16T10:46:22

Hi,

since everyone seemed to agree that it was a good idea, Migen is now 
licensed under 2-clause BSD.

Sebastien

[MiGen - Language Specification]

Khobatha Setetemela — 2013-04-13T21:55:54

Hi

May I ask you to help me with a copy of MiGen's language specification?I am
interested in knowing what operators, types and methods are available in
the language so that I may implement something useful on the RHINO using
the tool-chain.

Regards

[PATCH milkymist-ng] edid.py: sample SCL only every 64 clock cycles, to avoid bouncing

Werner Almesberger — 2013-04-12T20:38:31

Possibly due to SCL rising fairly slowly (in the 0.5-1 us range),
bouncing has been observed while crossing the "forbidden" region
between Vil(max) and Vih(min).

By lowering the sample rate from once per system clock to once
every 64 clock cycles, we make sure we sample at most once during
the bounce interval and thus never see a false edge. (Although we
may see a rising edge one sample time late, which is perfectly
harmless.)

---
 milkymist/dvisampler/edid.py |   17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/milkymist/dvisampler/edid.py b/milkymist/dvisampler/edid.py
index 4c9da42..f42b9df 100644
--- a/milkymist/dvisampler/edid.py
+++ b/milkymist/dvisampler/edid.py
< at >< at > -23,24 +23,25 < at >< at > class EDID(Module, AutoCSR):
 
 ###
 
-scl_i = Signal()
+scl_raw = Signal()
 sda_i = Signal()
 sda_drv = Signal()
 _sda_drv_reg = Signal()
 _sda_i_async = Signal()
 self.sync += _sda_drv_reg.eq(sda_drv)
 self.specials += [
-MultiReg(pads.scl, scl_i),
+MultiReg(pad

Downsampling SCL

Werner Almesberger — 2013-04-12T16:08:17

Sebastien suggested to simply use downsampling to get rid of the
glitches, given that I2C has very relaxed timing.

I added a 1:64 divider, yielding a sample rate of about 800 kHz
in this EDID test or 1.3 MHz on Milkymist-ng.

Overview, with raw SCL on D3, D2 changing each time we sample,
and D0-D1 showing the bit counter:

http://downloads.qi-hardware.com/people/werner/ming/edid/debounce-downs-64-overview.png

The obligatory glitch, having no effect whatsoever:

http://downloads.qi-hardware.com/people/werner/ming/edid/debounce-downs-64-glitch.png

Last but not least, the SCLK period vs. the sample rate:

http://downloads.qi-hardware.com/people/werner/ming/edid/debounce-downs-64-ratio.png

It's about 1:20 in this case. The code:

https://github.com/wpwrak/ming-ddc-debug/commit/12a216e1f78b8219e6fd3246c075ce1b407b57e8

Next: still have to pull the pull-up. Also need to try with
(an)other signal source(s) and see how slow/fast their signals
are.

- Werner

SCL stabilized

Werner Almesberger — 2013-04-12T15:01:46

Using the SCL delay buffer (20 entries), I added a count of the
number of times SCL was sampled high. If that count ends up > 7
I take SCL as asserted, otherwise not.

This is the code:

https://github.com/wpwrak/ming-ddc-debug/commit/a3d338cbcf361a1b5c379ae381604f02b207b731

On the scope it looks like this, with the SCL sum on D0 through
D3. Note that I still have the 1.5 kOhm pull-up:

http://downloads.qi-hardware.com/people/werner/ming/edid/debounce-thresh-7-sum.png

The numerous glitches on D0 through D3 are scope artefacts or
my code doing something wrong when bringing out the sum. If
SCL is constantly high, the count is 20, which is why D0-D3
show the value 4 after SCL has stabilized.

Here we have the "classical view", with the raw SCL input on
D3 and the SCL edge count on D0 through D2:

http://downloads.qi-hardware.com/people/werner/ming/edid/debounce-thresh-7-count-overview.png

Do you see the glitches ? Here's the first one:

http://downloads.qi-hardware.com/people/werner/ming/edid/debounce-thresh

a peek inside EDID's black box (I2C's, actually)

Werner Almesberger — 2013-04-12T06:04:12

I added instrumentation to track FPGA-internal state on my scope.
I first tried to have a look at the FSM state, but that's trickier
than I expected and may tell me less that I had hoped.

I then looked at the I2C bit counter (D0-D3, SDA yellow, SCL is
blue):

http://downloads.qi-hardware.com/people/werner/ming/edid/bouncy-counter.png

First, I thought my scope has worse glitching issues than usual
(the LA of Rigol series 1000 devices isn't all that great, and
this is worst in the early models, which of course is what I
have), but then I slowly realized that this can't really be scope
artefacts.

Note that the counter counts from 0 to 8 in only 4 rising SCL
edges. To properly interpret the data, we also need to take into
account the delay applied to SCL in the FPGA. For this, I
replaced D3 with a copy of SCL as seen by the FPGA (scl_i):

http://downloads.qi-hardware.com/people/werner/ming/edid/scl-glitch-1.62V.png

The bouncy rise of SCL begins at 1.24 V and ends at 2.00 V.
About 440 ns later, the counter sh