Tim 'mithro' Ansell | 12 Aug 13:28 2015

[M-Labs devel] [PATCH 0/3] Fixing the misoc clean target.

Hi,

I couldn't figure out why running "make.py clean" wasn't deleting things. The
root cause of the problem was that make.py was using globbing without passing
"shell=True" to the command. This command was actually failing, but as nothing
was checking the return code, nobody noticed the failure.

These patches add checks for all commands run in make.py and then fix the clean
target. The last "Use shutil rather then rm -rf" patch is option, but I think
worth doing as it should be more portable.

Tim 'mithro' Ansell

Tim 'mithro' Ansell (3):
  All commands run should be checked.
  Use shell for globbing in clean.
  Use shutil rather then rm -rf command.

 make.py | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

--

-- 
2.5.0.rc2.392.g76e840b

Ryan Verner | 3 Aug 14:31 2015
Picon

[M-Labs devel] [PATCH] Fix for fpgalink_programmer

Hello,

libfpgalink has changed its python API; this patch ports it to the new API as
per change at:

https://github.com/makestuff/libfpgalink/commit/2074e51a334f5a5c2ea78f4919d01b379d4ba2ef

Have tested this locally with my Atlys board and it works as expected.

Thanks,

R

---

Ryan Verner (1):
  Port fpgalink_programmer to use newer fl library.

 mibuild/fpgalink_programmer.py | 29 +++++++++++++++++------------
 1 file changed, 17 insertions(+), 12 deletions(-)

--

-- 
1.9.1

Philipp Schleifer | 29 Jul 00:40 2015
Picon

[M-Labs devel] 9914 DDS Clocking and syncing (Questions)

Hello Daniel, S├ębastien,

I have read your Emails regarding syncing multiple AD9914.

> As an update on the DDS syncing, it is looking like it should be
> possible to sync the DDS chips using pulses from the FPGA with
> variable delays, but this is preliminary and not fully shown yet.  It
> is essential that the edge time for the synchronization pulses be
> very fast, <400 ps is best for reliable performance.  This should be
> achievable using a OSERDES, correct?

I am a bit confused about how you want to adjust both SYNC_CLK.
Do you generate signals using OSERDES block that drive SYNC_IN pins of
AD9914s? Which frequency do you want to use to drive SYNC_IN? AD9914
datasheet figure 22 shows SYNC_OUT is driven at SYSCLK/384 (9.11 MHz).

In the Application Note for Syncing two AD9915, the statement is, that
SYNC_IN can be generated by an FPGA:

Note that SYNC_IN is not required to be driven by the SYNC_OUT output
of the master DDS device, but the SYNC_IN source rate must be at an
integer submultiple of the system clock rate and less than 50 MHz for
synchronization.

http://www.analog.com/media/en/technical-documentation/application-notes/AN-1254.pdf

Does the same thing applies to AD9914?. Do you expect better
synchronization results when using a higher SYNC_IN frequency?

What do you think about using programmable delay chip micrel SY89297U?
(Continue reading)

William D. Jones | 28 Jul 21:44 2015
Picon
Picon

[M-Labs devel] [PATCH] Add Mercury Programmer Support (Command Lines)

This patc adds programmer support to the Mercury mibuild target using a command-line programmer that I
wrote: https://github.com/cr1901/mercpcl

Flash support will be added after I decide on the best way to implement it.

William D. Jones (1):
  Add mercpl support for Mercury mibuild platform

 mibuild/platforms/mercury.py |  4 ++--
 mibuild/xilinx/programmer.py | 14 ++++++++++++++
 2 files changed, 16 insertions(+), 2 deletions(-)

--

-- 
2.4.3

Robert Jordens | 19 Jul 09:23 2015
Picon

[M-Labs devel] [PATCH 1/2] uart.c: rx overflow fix and tx simplification

* fixes the clearing of the rx ringbuffer on rx-overflow
* removes tx_level and tx_cts by restricting the ringbuffer
  to at least one slot empty
* agnostic of the details of the tx irq: works for uarts that
  generate tx interrupts on !tx-full or on tx-empty.
* only rx_produce and tx_consume need to be volatile
---
 software/libbase/uart.c | 71 ++++++++++++++++++++++++++-----------------------
 1 file changed, 37 insertions(+), 34 deletions(-)

diff --git a/software/libbase/uart.c b/software/libbase/uart.c
index 30ea5ef..6b16ed8 100644
--- a/software/libbase/uart.c
+++ b/software/libbase/uart.c
 <at>  <at>  -13,39 +13,37  <at>  <at> 

 static char rx_buf[UART_RINGBUFFER_SIZE_RX];
 static volatile unsigned int rx_produce;
-static volatile unsigned int rx_consume;
+static unsigned int rx_consume;

 #define UART_RINGBUFFER_SIZE_TX 128
 #define UART_RINGBUFFER_MASK_TX (UART_RINGBUFFER_SIZE_TX-1)

 static char tx_buf[UART_RINGBUFFER_SIZE_TX];
 static unsigned int tx_produce;
-static unsigned int tx_consume;
-static volatile int tx_cts;
-static volatile int tx_level;
+static volatile unsigned int tx_consume;
(Continue reading)

Numato Sales | 10 Jul 00:59 2015

http://numato.com/mimas-v2-spartan-6-fpga-development-board-with-ddr-sdram.html)

Below diff is to add mibuild support for Mimas V2 Spartan 6 FPGA 
platform 
(http://numato.com/mimas-v2-spartan-6-fpga-development-board-with-ddr-sdram.html). 
This is my first contribution to Migen. Any suggestions or corrections 
greatly appreciated.

Thanks,
Tom
Numato Lab

diff --git a/mibuild/platforms/mimasv2.py b/mibuild/platforms/mimasv2.py
new file mode 100644
 <at>  <at>  -0,0 +1,125  <at>  <at> 
+from mibuild.generic_platform import *
+from mibuild.xilinx import XilinxPlatform
+
+_io = [
+    ("clk100", 0, Pins("V10"), IOStandard("LVCMOS33")),
+    ("clk12", 0, Pins("D9"), IOStandard("LVCMOS33")),
+
+    ("serial", 0,
+        Subsignal("tx", Pins("A8"), IOStandard("LVCMOS33"), 
Misc("SLEW=FAST")),
+        Subsignal("rx", Pins("B8"), IOStandard("LVCMOS33"), 
Misc("SLEW=FAST"))
+    ),
+
+    ("spiflash", 0,
+        Subsignal("cs_n", Pins("V3")),
+        Subsignal("clk", Pins("R15")),
(Continue reading)

Tim Ansell | 5 Jul 16:00 2015

[M-Labs devel] Anyone using migen/misoc with FPGA's that have "hard cores" such as the Zynq or Cyclone SOC?

Hi,

Is anyone using migen+misoc on boards which also have hard ARM cores? I sure that migen+misoc would work perfectly generating the FPGA side of things but was wondering how it would integrate with the other side.

Despite having both a Digilent Zybo and a Cyclone V SoCKit, I haven't actually used them at all or looked at how the FPGA is programmed or accessed from the processor side. Do you know if it possible to just boot the processor like any other Linux system and then do some type of "virtual JTAG" to load stuff onto the FPGA?

There already exists some very good open systems like OpenEmbedded (or if you are crazy, Buildroot) for building embedded linux firmware. I guess you could just integrate the output of migen+misoc stuff into that?

Don't really have much time to work on it right now but am interested in following anyone who is play in this area to understand how things are progressing.

Tim 'mithro' Ansell
<div><div dir="ltr">Hi,<div><br></div>
<div>Is anyone using migen+misoc on boards which also have hard ARM cores? I sure that migen+misoc would work perfectly generating the FPGA side of things but was wondering how it would integrate with the other side.</div>
<div><br></div>
<div>Despite having both a Digilent Zybo and a Cyclone V SoCKit, I haven't actually used them at all or looked at how the FPGA is programmed or accessed from the processor side. Do you know if it possible to just boot the processor like any other Linux system and then do some type of "virtual JTAG" to load stuff onto the FPGA?</div>
<div><br></div>
<div>There already exists some very good open systems like OpenEmbedded (or if you are crazy, Buildroot) for building embedded linux firmware. I guess you could just integrate the output of migen+misoc stuff into that?</div>
<div><br></div>
<div>Don't really have much time to work on it right now but am interested in following anyone who is play in this area to understand how things are progressing.</div>
<div><br></div>
<div>Tim 'mithro' Ansell</div>
</div></div>
Tim 'mithro' Ansell | 5 Jul 10:43 2015

[M-Labs devel] [PATCH 0/2] Expand UrJTAG support

Hi,

These two patches allow me to program my Digilent Atlys board (when loaded with
ixo-usb-jtag - https://github.com/mithro/ixo-usb-jtag) using UrJTAG.
------------------------------------------------------------------------------
$ ./make.py -X ../HDMI2USB-misoc-firmware -t atlys -s VideomixerSoC \
 -Op programmer urjtag load-bitstream
                __  ___  _   ____     _____
               /  |/  / (_) / __/__  / ___/
              / /|_/ / / / _\ \/ _ \/ /__
             /_/  /_/ /_/ /___/\___/\___/

a high performance and small footprint SoC based on Migen

====== Building for: ======
Platform:  atlys
Target:    atlys
Subtarget: VideomixerSoC
CPU type:  lm32
===========================
Connected to libftdi driver.
IR length: 6
Chain length: 1
Device Id: 01000100000000001000000010010011 (0x44008093)
  Manufacturer: Xilinx (0x093)
  Part(0):      xc6slx45 (0x4008)
  Stepping:     3
  Filename:     /usr/share/urjtag/xilinx/xc6slx45/xc6slx45
Bitstream information:
        Design: atlys-videomixersoc-atlys.ncd;UserID=0xFFFFFFFF
        Part name: 6slx45csg324
        Date: 2015/07/03
        Time: 00:30:24
        Bitstream length: 1487444
------------------------------------------------------------------------------

I'm unsure about what the second patch is doing regarding CFG ops, but I found
the suggestion in the #milkymist logs and it seems to work. Without those
commands, I get the following error;
------------------------------------------------------------------------------
error: when parsing command 'pld load build/atlys-videomixersoc-atlys.bit'
error: pld subsystem: unknown instruction 'CFG_IN'
------------------------------------------------------------------------------

I also had to patch my urjag STEPPINGS file to make this work, otherwise I get
the following error;
------------------------------------------------------------------------------
jtag> detect
IR length: 6
Chain length: 1
Device Id: 01000100000000001000000010010011 (0x44008093)
  Manufacturer: Xilinx (0x093)
  Part(0):      xc6slx45 (0x4008)
  Unknown stepping! (0100) (/usr/share/urjtag/xilinx/xc6slx45/STEPPINGS)
------------------------------------------------------------------------------

I added the following line;
------------------------------------------------------------------------------
 0100    xc6slx45        3
------------------------------------------------------------------------------

Tim 'mithro' Ansell (2):
  Allow using non-milkymist cables with UrJTAG.
  Adding support for bypassing CFG ops.

 mibuild/platforms/m1.py      |  2 +-
 mibuild/xilinx/programmer.py | 23 +++++++++++++++++++----
 2 files changed, 20 insertions(+), 5 deletions(-)

--

-- 
2.4.3.573.g4eafbef

Marcelo Teixeira Rossi | 5 Jul 01:45 2015
Picon

[M-Labs devel] Want to buy Milkymist One!

Someone has a used Milkymist One for sell??



Marcelo Teixeira Rossi
Engenheiro Químico, Gestor de Sustentabilidade e Designer em Permacultura
http://marcelokitu.wix.com/zenocao
http://br.linkedin.com/in/marcelokitu
+55 11 982122619


<div><div dir="ltr">Someone has a used Milkymist One for sell??<div><br></div>
<div><br></div>
<div>
<br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<div>Marcelo Teixeira Rossi<br>Engenheiro Qu&iacute;mico, Gestor de Sustentabilidade e Designer em Permacultura<br><a href="http://marcelokitu.wix.com/zenocao" target="_blank">http://marcelokitu.wix.com/zenocao</a><br><a href="http://br.linkedin.com/in/marcelokitu" target="_blank">http://br.linkedin.com/in/marcelokitu</a><br>
</div>
<div>+55 11 982122619<br><br>
</div>
<div><br></div>
</div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
</div></div>
Tim 'mithro' Ansell | 2 Jul 14:45 2015

[M-Labs devel] [PATCH] Adding support for programming with FPGALink

This patch adds support for using the fpgalink to program compatible boards.
This allows a fully open source method of programming a large number of the
Digilent based boards and using NeroJTAG stand alone programmers.

Tim 'mithro' Ansell (1):
  Adding support for programming with FPGALink.

 mibuild/fpgalink_programmer.py | 89 ++++++++++++++++++++++++++++++++++++++++++
 mibuild/xilinx/programmer.py   | 13 +++++-
 2 files changed, 101 insertions(+), 1 deletion(-)
 create mode 100644 mibuild/fpgalink_programmer.py

--

-- 
2.4.3.573.g4eafbef

Tim 'mithro' Ansell | 2 Jul 14:41 2015

[M-Labs devel] [PATCH] Adding support for programming with the Digilent Adept tools.

*** BLURB HERE ***

Tim 'mithro' Ansell (1):
  Adding programming with the Digilent Adept tools.

 mibuild/xilinx/__init__.py   |  2 +-
 mibuild/xilinx/programmer.py | 27 +++++++++++++++++++++++++++
 2 files changed, 28 insertions(+), 1 deletion(-)

--

-- 
2.4.3.573.g4eafbef


Gmane