from:"Sébastien Bourdeauducq"

On 12/09/2013 04:15 PM, Salman Sheikh wrote:
 /cygdrive/c/Python33/python setup.py install
 Traceback (most recent call last):
   File setup.py, line 4, in module
 from setuptools import setup
 ImportError: No module named 'setuptools'
 
 
  I am having problems installing setuptools...
 

Just add the Migen/MiSoC directories to PYTHONPATH and ignore setup.py.

Sébastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] MiSOC on Cygwin

On 12/09/2013 04:44 PM, Salman Sheikh wrote:
 $ make
 ./build.py
 /usr/bin/env: python3: No such file or directory
 Makefile:4: recipe for target 'build/top.bit' failed
 make: *** [build/top.bit] Error 127

Can you successfully run python3 on the Cygwin shell? And env
python3? If not then either make it so or modify the shebang line in
make.py so it runs your Python 3.3 interpreter.

What is the company you are working for?

Sébastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] MiSOC on Cygwin

On 12/09/2013 04:44 PM, Salman Sheikh wrote:
 $ make
 ./build.py
 /usr/bin/env: python3: No such file or directory

Also I would recommend that at some point you adapt this port to the new
MiSoC build system (https://github.com/m-labs/misoc) which reduces code
duplication across ports. The author of the nexys3 port hasn't updated
it for a while...

Sébastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] MiSOC on Cygwin

On 12/09/2013 05:41 PM, Salman Sheikh wrote:
 I have linked /usr/bin/python to python in c:\Python3.3\

Have you noticed that make.py attempts to run python3, not python?

 ...I can run it on command line shell only if I add '-i' to it...

And what happens otherwise?


___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] LM32 in yosys-bigsim

2013-12-05 Thread Sébastien Bourdeauducq

Hi,

I can reproduce the problem with your sieve.vh. Note that it does not
actually use the barrel shift instruction - instead GCC emits calls to
the software implementation __ashlsi3 which is in in libgcc.

The gateware barrel shifter is however enabled in lm32_config.v. I have
added the -mbarrel-shift-enabled option to GCC (I use compiler-rt here
instead of libgcc, and it does not provide ashlsi3), removed -lgcc, and
recompiled. The test now produces better output:

OUT:  2
OUT:  3
OUT:  5
OUT:  7
OUT: 11
OUT: 13
OUT: 17
OUT: 19
OUT: 23
[...]
OUT: 89
OUT: 97
OUT:101
OUT:103
OUT:107
OUT:109
OUT:113
OUT:127

I have attached my sieve.vh. I do not use the Lattice GCC binaries, it's
easier to compile from source:
https://github.com/m-labs/misoc/blob/master/README#L9

Sebastien

@000  98 00 00 00 78 1c 00 00 3b 9c ff fc b8 00 d8 00
@010  78 01 00 00 38 21 80 00 78 02 00 00 38 42 80 08
@020  4c 22 00 04 58 20 00 00 34 21 00 04 e3 ff ff fd
@030  f8 00 00 45 78 01 de ad 38 02 be ef 58 22 00 00
@040  37 9c ff f4 5b 9b 00 08 5b 9d 00 04 34 1b 00 0c
@050  b7 7c d8 00 5b 61 00 00 2b 61 00 00 00 22 00 05
@060  78 01 00 00 38 21 80 00 3c 43 00 02 b4 23 08 00
@070  28 23 00 00 2b 61 00 00 20 21 00 1f 34 04 00 01
@080  bc 81 08 00 b8 61 18 00 78 01 00 00 38 21 80 00
@090  3c 42 00 02 b4 22 08 00 58 23 00 00 2b 9b 00 08
@0a0  2b 9d 00 04 37 9c 00 0c c3 a0 00 00 37 9c ff f4
@0b0  5b 9b 00 08 5b 9d 00 04 34 1b 00 0c b7 7c d8 00
@0c0  5b 61 00 00 2b 61 00 00 00 22 00 05 78 01 00 00
@0d0  38 21 80 00 3c 42 00 02 b4 22 08 00 28 22 00 00
@0e0  2b 61 00 00 20 21 00 1f 34 03 00 01 bc 61 08 00
@0f0  a0 41 08 00 7c 21 00 00 20 21 00 ff 2b 9b 00 08
@100  2b 9d 00 04 37 9c 00 0c c3 a0 00 00 37 9c ff f4
@110  5b 9b 00 08 5b 9d 00 04 34 1b 00 0c b7 7c d8 00
@120  5b 61 00 00 78 01 ff 00 38 21 00 04 2b 62 00 00
@130  58 22 00 00 2b 9b 00 08 2b 9d 00 04 37 9c 00 0c
@140  c3 a0 00 00 37 9c ff ec 5b 9b 00 08 5b 9d 00 04
@150  34 1b 00 14 b7 7c d8 00 34 01 00 02 fb ff ff ec
@160  34 01 00 00 5b 61 00 00 e0 00 00 29 2b 61 00 00
@170  fb ff ff cf b8 20 10 00 34 01 00 00 5c 41 00 20
@180  2b 61 00 00 3c 21 00 01 34 21 00 03 fb ff ff e0
@190  2b 61 00 00 3c 21 00 02 34 21 00 06 5b 61 ff fc
@1a0  2b 61 ff fc 20 22 00 01 34 01 00 00 44 41 00 0c
@1b0  2b 61 ff fc 34 21 ff fd 00 21 00 01 5b 61 ff f8
@1c0  2b 61 ff f8 34 02 00 3f 50 41 00 02 e0 00 00 0d
@1d0  2b 61 ff f8 fb ff ff 9b e0 00 00 02 34 00 00 00
@1e0  2b 61 00 00 3c 22 00 01 2b 61 ff fc b4 41 08 00
@1f0  34 21 00 03 5b 61 ff fc e3 ff ff ea 34 00 00 00
@200  2b 61 00 00 34 21 00 01 5b 61 00 00 2b 61 00 00
@210  34 02 00 3f 50 41 ff d6 34 01 00 00 2b 9b 00 08
@220  2b 9d 00 04 37 9c 00 14 c3 a0 00 00
___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] [PATCH] cordic improvements

Hi,

merged your very nice patches, thanks! What is the target board (if it's
real) in examples/cordic/cordic_impl.py? Would it make any sense to put
it into mibuild/platforms?

Sebastien
___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] Migen on EDA Playground

Hi,

Good news :)

On 12/02/2013 04:14 PM, Victor Lyuboslavsky wrote:
 (http://www.edaplayground.com/s/example/453). It would be good to have a
 Migen example on EDA Playground that is both synthesizable and has a
 simple testbench

I have written a quick testbench code for the divider, it's below.

If you upgrade Migen, the lines:
s = Simulator(TB())
s.run()
should be replaced with:
with Simulator(TB()) as s:
s.run()

The divider had a little bug :) 
https://github.com/m-labs/migen/commit/ae6b78faeb9fe45bcafe6be1133d7b6fbf75c9ed

Sebastien

# Code your testbench here
from design import * # from over there --
from migen.sim.generic import Simulator

class TB(Module):
def __init__(self):
self.submodules.divider = Divider(8)
self.p = 0
self.q = 1
self.state = LOAD

def do_simulation(self, s):
if self.state == LOAD:
s.wr(self.divider.dividend_i, self.p)
s.wr(self.divider.divisor_i, self.q)
s.wr(self.divider.start_i, 1)
self.state = WAIT0
elif self.state == WAIT0:
self.state = WAIT
elif self.state == WAIT:
s.wr(self.divider.start_i, 0)
if s.rd(self.divider.ready_o):
quotient = s.rd(self.divider.quotient_o)
remainder = s.rd(self.divider.remainder_o)
print({} = {}*{} + {}.format(self.p, self.q, quotient, 
remainder))
assert(quotient == self.p // self.q)
assert(remainder == self.p % self.q)
self.p += 1
if self.p == 30:
self.p = 0
self.q += 1
if self.q == 7:
s.interrupt = True
self.state = LOAD

def main():
s = Simulator(TB())
s.run()

if __name__ == __main__:
main()

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] Migen on EDA Playground

On 12/02/2013 05:59 PM, Sébastien Bourdeauducq wrote:
 elif self.state == WAIT0:
 self.state = WAIT
 elif self.state == WAIT:
 s.wr(self.divider.start_i, 0) = this should be moved up 2 lines


___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] Migen on EDA Playground

The whole thing is also quite ugly. I guess the divider should use DF
(and be moved to actorlib in Migen) so that the testbench can use the
Token transaction objects instead of this little mess :)

Sebastien
___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] Migen on EDA Playground

2013-12-01 Thread Sébastien Bourdeauducq

On 11/30/2013 03:36 PM, Victor Lyuboslavsky wrote:
 Sebastien,
 Can you add a link to Migen documentation? Something like: EDA
 Playground -- run Migen simulations online

Sure:
http://milkymist.org/3/migen.html
https://twitter.com/Milkymist_Labs/status/406825848226848769

By the way I found http://www.clifford.at/yosys/about.html via your
website, and it looks pretty cool :)

Thanks,
Sebastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] Testing new Mixxeo boards

2013-11-29 Thread Sébastien Bourdeauducq

Hi,

On 11/29/2013 05:38 PM, Adrian Byszuk wrote:
 All boards tested. There were a few minor errors in mounting of PCB 
 that we corrected.
 All HDMI inputs work, VGA and DVI outputs work. Ethernet works.

Excellent news :)

 DDC channel wasn't tested.

Which one? On the HDMI input ports, or on the DVI output port?

Regards,
Sebastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

[M-Labs devel] anyone near Amsterdam on Dec 15th?

2013-11-28 Thread Sébastien Bourdeauducq

We are invited to present at Hardware Freedom Day at FabLab Amersfoort:
https://twitter.com/HFDNL/status/405815687748534272

Sebastien
___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] Migen on EDA Playground

2013-11-28 Thread Sébastien Bourdeauducq

On 11/27/2013 11:52 PM, Victor Lyuboslavsky wrote:
 2. Ask the user to enter the top level Module class and the list of
 ports. And then I simply run print(verilog.convert(UserModule(),
 ios{ports})) on the server.

I would be in favor of that. You can pre-fill the list of modules by
analyzing the source code:

 from migen.fhdl.std import *
 from migen.genlib import divider # you can also use importlib (see
MiSoC make.py for an example)
 {name for name, cl in divider.__dict__.items() if isinstance(cl,
type) and cl is not Module and issubclass(cl, Module)}
{'Divider'}

Then after the user has provided any required parameters (you can use
Python introspection to get the parameter list of the __init__ method),
you can pre-fill the port list:

 top = divider.Divider(5)
 {name for name in dir(top) if name[0] != _ and
isinstance(getattr(top, name), Signal)}
{'divisor_i', 'remainder_o', 'dividend_i', 'start_i', 'quotient_o',
'ready_o'}

This code does not cover all cases, but it should be nice for simple
designs.

Sebastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] [PATCH] API documentation

2013-11-28 Thread Sébastien Bourdeauducq

Hi,

merged and added some clarification of what happens when you attempt to
load the FIFO when writable=0 (this is useful e.g. when you are pushing
data continuously from one clock domain - you can tie we to 1).

Do you know how to make the Python module index section more useful,
or disable it completely?

Sebastien


On 11/28/2013 09:57 AM, Robert Jördens wrote:
 Hello,
 migen so far has excellent tutorial-style documentation from Sebastien
 but there should also be API documentation for the individual modules.
 If the numpydoc format is used for docstrings, the API documentation
 can be generated quickly. These patches get the API documentation
 started but obviusly there are still a lot of docstrings to be
 written.
 
 Examples/doctests could also be included in the docstrings but
 unfortunately the amount of required boilerplate code (basically a
 testbench) is large.
 

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] MiSoC portability

Hi,

On 11/27/2013 08:03 AM, David Carne wrote:
 If mibuild is to be merged into / maintained with migen - could we
 consider removing the platforms/ tree from migen (and moving it into
 misoc)? It seems to me that most of the contents of the platforms
 folder is milkymist-specific.

Not really, M1 and Mixxeo are among a total of 9 boards there; many are
Xilinx/Altera devboards. And all can be used without MiSoC, if only for
the Migen tutorial, and the rhino platform file is also used in a
larger project that does not use MiSoC:
https://github.com/brandonhamilton/rhino-gateware

Also note that you can still use Migen without Mibuild (the distribution
into a single repository is really just a practical convenience) and
that you can put your own platform files anywhere Python would import them.

Sebastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

[M-Labs devel] EHSM-2014 CFP - pushing the frontiers of open source and DIY

   CALL FOR PARTICIPATION

 Exceptionally Hard  Soft Meeting
pushing the frontiers of open source and DIY
 DESY, Hamburg site, June 27-29 2014
   http://ehsm.eu
@ehsmeeting

Collaboration between open source and research communities empowers open
hardware to explore new grounds and hopefully deliver on the third
industrial revolution. The first edition of the Exceptionally Hard and
Soft Meeting featured lectures delivered by international makers,
hackers, scientists and engineers on topics such as nuclear fusion, chip
design, vacuum equipment machining, and applied quantum physics.
Tutorials gave a welcoming hands-on introduction to people of all
levels, including kids.

EHSM is back in summer 2014 for another edition of the most cutting-edge
open source conference. This year we are proud to welcome you to an
exceptional venue: DESY, Europe's second-largest particle physics
laboratory!

Previous EHSM lectures may be viewed at: http://ehsm.eu/2012/media.html

ATTEND WITHOUT PRESENTING:
Attendance is open to all curious minds.

EHSM is entirely supported by its attendees and sponsors. To help us
make this event happen, please donate and/or order your ticket as soon
as possible by visiting our website http://ehsm.eu.
Prices are:
* 45E - student/low-income online registration
* 70E - regular online registration (until February 1st)
* 95E - late online registration (after February 1st)
* 110E - door ticket
* 272E - supporter ticket, with our thanks and your name on the website.
* 1337E - gold supporter ticket, with our thanks and your
  company/project logo on the website and the printed programme.
EHSM is a non-profit event where the majority of the budget covers
speakers' travel and transportation of exhibition equipment.

SPEAKERS: SUBMIT YOUR PRESENTATION
Is there a device in your basement that demonstrates violations of
Bell's inequalities? We want to see it in action. Are you starting up a
company to build nuclear fusion reactors? Tell us about it. Does your
open source hardware or software run some complex, advanced and
beautiful scientific instruments? We are eager to learn about it. Do you
have stories to tell about your former job manufacturing ultra high
vacuum equipment in the Soviet Union? We want to hear about your
experiences. Do you have a great design for a difficult open source
product that can be useful to millions? Team up with the people who can
help implement your ideas.

Whoever you are, wherever you come from, you are welcome to present
technologically awesome work at EHSM. Travel assistance and visa
invitation letters provided upon request. All lectures are in English.

This year, we will try to improve the conference's documentation by
publishing proceedings. When relevant, please send us a paper on your
presentation topic. We are OK with previously published work, we simply
expect high quality and up-to-date content.

To submit your presentation, send a mail to t...@ehsm.eu with typically
the following information:
* Your name(s). You can be anonymous if you prefer.
* Short bio
* Title of the presentation
* Abstract
* How much time you would like
* Full paper (if applicable)
* Links to more information (if available)
* Contact information (e-mail + mobile phone if possible)
* If you need us to arrange your trip:
  * Where you would be traveling from
  * If you need accommodation in Hamburg

We will again have an exhibition area where you can show and demonstrate
your work - write to the same email address to apply for space. If you
are bringing bulky or high-power equipment, make sure to let us know:
* What surface you would use
* What assistance you would need for equipment transport between your
  lab and the conference
* If you need 3-phase electric power
  (note that Germany uses 230V/400V 50Hz)
* What the peak power of your installation would be

Tutorials on any technology topic are also welcome, and may cater to all
levels, including beginners and kids.

We are counting on you to make this event awesome. Feel free to nominate
other speakers that you would like to see at the conference, too - just
write us a quick note and we will contact them.

KEY INFORMATION:
Conference starts: morning of June 27th, 2014
Conference ends: evening of June 29th, 2014
Early registration fee ends: February 1st, 2014
Please submit lectures, tutorials and exhibits before: May 15th, 2014

Conference location:
DESY
Notkestrasse 85
22607 Hamburg, Germany

WE ARE LOOKING FORWARD TO WELCOMING YOU IN HAMBURG!
- EHSM e.V. http://ehsm.eu
___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] Testing new Mixxeo boards

Hi,

On 11/27/2013 01:44 PM, Adrian Byszuk wrote:
 With the soc-mixxeo-ports23 bitstream I get something like this in console
 
 when connecting to port HDMI3:
 dvisampler1: PLL locked
 IDELAY busy timeout
 dvisampler1: delays calibrated
 dvisampler1: phase init OK
 dvisampler1: ph:   000 // charsync:000 [0 0 0] // WER:  0   0   0 // 
 chansync:0 // res:0x0

Does it keep printing that (it should repeat at ~1Hz), or does it go
into the disconnected state immediately after?
You should not have the IDELAY busy timeout messages, and the numbers
should be non-zero. Also WER=0 means either no transmission errors
(which is unlikely since the delay calibration failed) or no data at all
(signal lines completely idle). Have you checked the TMDS signals for
short circuits, possibly coming from the TVS solders?

 BUT, I think that with soc-mixxeo.bit bitstream SoC hangs soon after loading 
 netboot firmware
 because with the ports23 bitstream I can see a continous output stream on 
 console:
   read: 3008Mbps  write:0Mbps  all: 3008Mbps
 also, LED2 is blinking with ~1Hz frequency.

Yes, you should keep seeing those messages on the console while the
firmware is running. LED2 is just the serial transmission indicator,
hardwired to the FTDI-chip.

 With the ports01 bistream console output freezes soon after loading netboot 
 firmware,
 for example during
   read: 3008Mbps  write:0Mbps  all: 3008Mbps
 or 
   waiting for LOCKED...ok
 and LED2 stops blinking.

This is weird... Don't you see any other messages before the freeze?

Sebastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] MiSoC portability

On 11/27/2013 04:27 AM, Robert Jördens wrote:
 That sounds good! It makes reusing the soc components much simpler.
 But I think misoclib and make.py should become a python package. Then,
 one could separate one's own history from that of misoc.
 A project using misoc would comprise only the custom target, custom
 cores, and custom apps and not need to be a branch of misoc.

That's already the case with the -Xt/-Xp options, isn't it? You would
not need to change misoc itself, or make only minor changes that
hopefully can be merged in a simple way.

 Whether shipping bios source code and the verilog parts as data
 would be the right way, I don't know.

I hope that the BIOS can be made small and generic enough that it can
work on all targets... or maybe become extendable at some point with a
mechanism similar to -Xt/-Xp to add external modules. Ideally, there
would be no Verilog parts.

Sebastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] Testing new Mixxeo boards

On 11/27/2013 03:55 PM, Adrian Byszuk wrote:
  Does it keep printing that (it should repeat at ~1Hz), or does it go
  into the disconnected state immediately after?
 It goes into disconnected state immediately after. Basically screen is
 flooded with these messages.

That could be the Spartan-6 PLL phantom lock feature. I guess you did
not have the HDMI output enabled on your laptop?
I have added a filter later on the PLL lock output to fix this bug. The
new binaries below should not have the problem.

 This is weird... Don't you see any other messages before the freeze?
 
 No, it's just that it freezes suddenly. I've checked this with another
 board and I have the same symptoms. It even freezes much sooner, always
 after 'Executing booted program.' line.

I just tried this exact binary on a board I have and it also tends to be
very unstable, even though it does not crash immediately after startup
here. It could be a ISE timing model/PR intermittent bug that affected
that bitstream, it happens sometimes...

I have compiled new binaries that hopefully will address both problems
(you need to reflash bios.bin):
http://milkymist.org/mixxeo_binaries_2.tar.bz2
I did not trust ISE this time and verified that everything is stable
enough on the board...

Press capital 'D' after videomixer.bin is loaded to enable HDMI
debugging messages. You can also press 'm' to display the memory
bandwidth statistics (it does not do so every second like the old
firmware did).

Additionally, you will find the memtest.bin firmware that you can
netboot to stress-test the SDRAM.

Sebastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] Migen on EDA Playground

Hi,

can we take this discussion to the developer mailing list? You may need
to subscribe at http://lists.milkymist.org so your messages do not go
into the moderation queue and you'll get the possible answers from other
people.

On 11/27/2013 05:49 PM, Victor Lyuboslavsky wrote:
 I tried migen, and I'm running into problems simulating.
 I have iverilog 0.9.6 installed in a custom directory
 (/usr/share/iverilog-0.9.6) and migensim.vpi installed in
 /usr/share/iverilog-0.9.6/lib/ivl. It is not clear how to give this
 information to migen -- are there environment variables I should set?
 Using Ubuntu 12.04
 
 Here is my run:
 root@precise64:/work/migen/examples/sim#
 /usr/share/python3.3.3/bin/python3 basic1.py
 Traceback (most recent call last):
   File basic1.py, line 35, in module
 main()
   File basic1.py, line 30, in main
 sim = Simulator(dut)
   File /work/migen/migen/sim/generic.py, line 88, in __init__
 self.ipc = Initiator(sockaddr)
   File /work/migen/migen/sim/ipc.py, line 145, in __init__
 self.socket.bind(self.sockaddr)
 PermissionError: [Errno 1] Operation not permitted

This sounds like you do not have permission to create a unix socket in
the current directory, or the filesystem does not support it. Can you
run mkfifo successfully there?

 Question #2. Is it possible to have a generic script that takes a migen
 Python file, finds the top level and the ports, and creates a
 synthesizable Verilog file. For example: custom_script migen.py  migen.v
 This would help with having a more streamlined synthesis flow. I'm not a
 Python expert, so I'm not sure how to do this easily.

Partly.

The ports, and the hierarchy, can be defined at runtime by an algorithm.
There is also no clear definition of 'port', but for many practical
purposes I think you can assume that all Signal members of Modules whose
names do not start with underscores are ports. For extracting the
hierarchy, you would need to try instantiating every class defined in
the module and see which classes are submodules of which, then take the
top of the tree(s).
Note that in some designs, many classes require parameters for which
they do not provide default values, and that script would not be able to
find values for them.

Sebastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] Migen on EDA Playground

On 11/27/2013 05:49 PM, Victor Lyuboslavsky wrote:
 This would help with having a more streamlined synthesis flow.

Have you tried the Migen tutorial with Mibuild?
http://milkymist.org/3/migen-tutorial.pdf

Do you see improvements for it?

Sebastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [M-Labs devel] Testing new Mixxeo boards

2013-11-26 Thread Sébastien Bourdeauducq

Hi,

On 11/26/2013 01:03 PM, Adrian Byszuk wrote:
 However, with no luck so far. Are the instructions at wiki complete?
 Particularly, what about this TFTP server that is mentioned? Shouldn't I
 upload some additional firmware via netboot?

The board will download that firmware from the TFTP server, both at
power-up and later if you enter netboot at the BIOS prompt (in case
the first attempt failed). You can find it as videomixer.bin in the
mixxeo_binaries_1.tar.bz2 archive I sent to Greg, rename it to boot.bin
and place it at the root of the TFTP server.

What do you see on the serial console? Open a serial terminal program
such as GtkTerm on /dev/ttyUSB0 with 115200bps 8-N-1 communication
parameters.

 I've succesfully flashed the SoC and BIOS with command 'm1nor-ng
 soc-mixxeo.fpg bios.bin'. HPD pin stays low.

Yes, this is expected, and the videomixer.bin firmware should drive them
high.

Regards,
Sebastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

[M-Labs devel] MiSoC portability

2013-11-25 Thread Sébastien Bourdeauducq

Hi Robert,

On 11/15/2013 11:47 PM, Robert Jordens wrote:
 what are your plans for the LX9 microboard? I don't know if you want
 full support for it merged into MiSoC (which would perhaps require some
 changes to the code organization).
 
 I am using it as a portable testbed for a few fpga ideas. And in general
 it would be nice if the migen/build/soc stack would offer baseline
 implementations for other boards. Since many boards are going to reuse a
 lot of the misoc cores, I would suggest to split the reusable parts from
 misoc.

I have implemented some changes in that direction. I have split the
top.py file into a gensoc library that provides platform-independent
integration components, and some targets that add peripherals and
platform-dependent cores to gensoc. Additional platform-dependent
constraints are also moved out of the build system and into the targets.

I have also added -Xt and -Xp options to make.py, that enable it to load
target and platform definitions from external directories. Those
external targets may of course use misoclib. This approach allows the
BIOS code to be shared, and avoids having several sets of generated
files around (sdram_phy.h, csr.h, etc.) which could easily lead to
external software including the wrong file.

The reset vector of LM32 is also set depending on the platform. It's
done in a slightly hacky way at the moment, it would be nice to have
LM32 rewritten in Migen at some point (also to avoid reset-related
problems).

The example target simple contains a basic SoC that works on the
Papilio Pro (http://papilio.cc/index.php?n=Papilio.PapilioPro), as a
test for the build system and a design with lower barriers to entry.
Significant missing parts are:
* BIOS XIP - I have merged and mapped your SPI flash core, and it works,
but the build system needs to be modified to run xc3sprog and load the
BIOS into the flash (or UrJTAG with the addition of SPI flash support)
* SDRAM - the Papilio Pro uses old PC133 SDR, and s6ddrphy needs some
modifications for supporting it.

 Alternatively misoc could become a python package. Better yet,
 those cores that are basically hardware independent could in fact be
 moved to migen. Drawing the migen/misoc line between algorithmic and
 protocol cores appears artificial.

Well, many of the cores in MiSoC are oriented towards building a
system-on-chip, and Migen is not specifically made for SoCs. Most
non-SoC FPGA designs do not need a UART or a timer for example, as such
functionality is already provided by whatever hard microcontroller/hard
SoC the device is using.

 Again IMHO having three separate
 packages is unnecessary. At least mibuild and migen should be merged:
 migen is rarely used without mibuild, mibuild pulls in no further
 dependencies, and mibuild requires migen.

Ok, I see it would be more practical to distribute them together. I have
put them into the same repository.

Sebastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [Milkymist-devel] Routing video out of Ableton Live thru the Milkymist

2013-10-23 Thread Sébastien Bourdeauducq

Hi,

On 10/23/2013 09:08 PM, Gabriel Shalom wrote:
 This would be contingent on being able to modify a Milkymist to accept
 my second monitor output so that Ableton's HD video (in my case, the material 
 I am using is 1920x1080) preview signal is routed through 
 the Milkymist to a digital HD projector. 
 The idea is to have one knob control an audio filter 
 and video filter at the same time.
 
 What do you think? Is this crazy? Difficult? Impossible?

Flickernoise does not support HD video, and there is no existing
development effort in this direction. While the current M1 hardware is
capable of 1080p video output with software graphics, implementing the
Flickernoise FPGA-accelerated effects at that resolution would require
more memory bandwidth than the hardware has. So you would need a new PCB
design with faster memory, and many other complexities, to run
Flickernoise at a full 1080p.

(Mixxeo, on the other hand, will support 720p60 and 1080p30 mixing with
various blend modes. But no Flickernoise effects.)

Sebastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [Milkymist-devel] Fwd: NOR FLASH

2013-08-24 Thread Sébastien Bourdeauducq


On 08/24/2013 01:26 AM, Werner Almesberger wrote:

sebastien.bourdeaud...@lekernel.net  wrote:

Any comments on that?

The pinout seems to be quite different ...


Found a better one. Same series, same pinout, smaller density, a little 
faster.

http://www.micron.com/parts/nor-flash/parallel-nor-flash/js28f640j3f75a
http://www.digikey.com/product-detail/en/JS28F640J3F75A/557-1602-ND/3927557
http://components.arrow.com/part/detail/49686317S8557478N1037

Sebastien

___
Devel mailing list
Devel@lists.milkymist.org
https://ssl.serverraum.org/lists/listinfo/devel

Re: [Milkymist-devel] Milkymist SoC on Nexys3 board

2013-05-20 Thread Sébastien Bourdeauducq


On 05/20/2013 06:03 PM, Yann Sionneau wrote:

Next step would be to try to serialboot a small application (small
enough to fit into the 4 kB SRAM).


Be careful that the BIOS uses that SRAM for the stack and some variables 
already.


___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Mibuild : Support for Xilinx Vivado toolchain

2013-05-20 Thread Sébastien Bourdeauducq


On 05/20/2013 06:23 PM, Werner Almesberger wrote:

Did the output actually work ?


Could not test, I don't have a 7 series board around yet.

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Mibuild : Support for Xilinx Vivado toolchain

2013-05-19 Thread Sébastien Bourdeauducq


On 05/20/2013 12:33 AM, Florent Kermarrec wrote:

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...


I tried implementing a LED blinker with one of the first Vivado 
versions, and concluded it was unusable bloatware after it took more 
than 10 minutes to compile it.


Strangely enough, I tried synthesis+PR of LM32 more recently, and it 
completed just under a minute. I don't have my Vivado install anymore so 
I can't quickly test your design, but will do that when I have some 
spare time.


Sebastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] preorders for the first Mixxeo prototype boards

2013-05-18 Thread Sébastien Bourdeauducq


On 05/13/2013 11:29 PM, Sébastien Bourdeauducq wrote:

Please send me an email before May 23 if you are interested!


Due to the design files taking longer than I had thought, this is 
extended until June 5th.


Check out the Swedish VJ Union article posted today:
http://www.vjunion.se/2013/05/the-mixxeo-hdmidvi-mixer-project/

Sebastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Patch to fix a simple stale test bench

2013-05-15 Thread Sébastien Bourdeauducq


On 05/15/2013 12:08 PM, toby @ tobyz wrote:

Which leads to the questions - is the present M1 implementation limited to 1:1 
pixel mapping between inputs and output, and is there an alternative route you 
were intending to implement that doesn't have the pixel shader with sampler 
approach?


Yes, using EDID first to force some resolution at the inputs. The FPGA 
can control the hotplug detect pins of the input ports. So it would work 
as follows:

1) the Mixxeo inputs ports appear completely disconnected to the two sources
2) the Mixxeo output is connected, the M1 reads the EDID and sets a 
screen resolution
3) the Mixxeo rewrites the EDID of the inputs to make the two sources 
have the same resolution as the output
4) the Mixxeo enables the hotplug detect of the inputs and the sources 
detect the new connections, read the EDID, and start generating video


It is much simpler than good resizing with bilinear filtering, which 
could come later with a firmware upgrade.


M3 platform is also for later. Mixxeo is still based on the M1 design.

Sebastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Patch to fix a simple stale test bench

2013-05-15 Thread Sébastien Bourdeauducq


On 05/15/2013 12:45 PM, toby @ tobyz wrote:

If you have / find / want to code the dynamic generation of EDIDs, thats 
something I could concretely collaborate around.


Cool, thanks for proposing. Will think of that!


It is much simpler than good resizing with bilinear filtering, which could come 
later with a firmware upgrade.


Which was part of my question: is the M1 hardware capable and/or could the 
pixel shader approach be implemented now in limited form as a base for future 
such goodness as billinear filtering etc.


Resizing with bilinear filtering is definitely possible on a Slowtan-6 
FPGA (the legacy SoC TMU already does that). Full pixel shader with 
arbitrary bilinear sampling I'll have to think of it.


Good performance is difficult, especially as you are supposed to output 
more than one pixel per system clock cycle if you want a decent 
resolution. Remember that each output pixel requires accessing 8 input 
pixels just for mixing 2 sources with bilinear filtering, so the memory 
system becomes very challenging especially with the ludicrous routing 
delays of my favorite FPGA.



Note: differing frame rates are also going to require temporal sampling or 
other such sophistication.


The current code handles that already. It's even tested (60/72/75 - 
60Hz) and works :)


Sebastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Patch to fix a simple stale test bench

2013-05-13 Thread Sébastien Bourdeauducq


Hi,

On 05/13/2013 06:31 AM, Larry Doolittle wrote:

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!


Thanks! I'm curious, what are you planning to do with it?

I'm working mostly on milkymist-ng those days 
(https://github.com/milkymist/milkymist-ng) but it does not have a PFPU.



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).


Merged it, thanks.


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?


Back when I developed this, there were some issues with Icarus Verilog, 
and that's why there is support for several simulators. But as far as I 
can tell, those problems have been resolved now, and unlike cver, Icarus 
Verilog is in active development. I'd rather focus only on the latter.


Sebastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] preorders for the first Mixxeo prototype boards

2013-05-13 Thread Sébastien Bourdeauducq


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 
resolution is 720p (limited by the Slowtan6 SERDES), getting there will 
need some more FPGA design work. Perhaps 1080p30 would work too, but not 
1080p60. [*]
* DVI output (analog + digital) from the M1r4 design. The digital part 
will need new gateware design.

* Ethernet (same as M1)
* Built-in FT2232H JTAG/UART adapter
* Same flash and DDR SDRAM as the M1
* Power via micro-USB connector. Power supply is not included.
* Larger IO connector from the M1r4 design
* No other M1 peripherals (USB, MIDI, DMX, analog video in, memory card, 
etc. are gone)

* Knobs and user interface elements not included (use IO connector)

Here are the nasty details:
* Price depends on how many boards are made and rapidly decreases with 
quantity. If too few people order, it can be up to 700 EUR/board 
(including VAT).

* Payment in advance.
* The board is sold as is, with all faults - you'll get the board 
straight from the assembly line with minimal testing. Of course, they 
should work, but if it were easy it would not be called hardware and you 
may end up having to fix some things yourself. Basically, you'd be 
sharing some of the risk with me.
* You will get to review the final design files for at least one week 
before they go into production.


Please send me an email before May 23 if you are interested!

Sebastien

[*] http://hamsterworks.co.nz/mediawiki/index.php/Spartan_6_1080p is a 
remarkable hack for the output, but I don't think it could easily work 
for the inputs. Memory bandwidth would become a problem too.

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] First digital video (DVI/HDMI) mixing on the Milkymist One

2013-05-12 Thread Sébastien Bourdeauducq


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

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

Sebastien
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] [PATCH] mibuild: Add platform for Xilinx ML605 board

2013-05-07 Thread Sébastien Bourdeauducq


Added it, thanks!

On 05/07/2013 12:22 AM, Florent Kermarrec wrote:

Ok it's done (I just want to keep user_btn_c, user_btn_n, etc... since I
find it easier for the KC705 than using user_btn(0) -- user_btn(N))

Florent


___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] [PATCH] mibuild: Add platform for Xilinx ML605 board

2013-05-06 Thread Sébastien Bourdeauducq


Hi Brandon,

committed it, thanks!

Does anyone else on this list have Migen/Mibuild patches that can be 
merged? Please send them in :)


Sebastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] [PATCH] mibuild: Add platform for Xilinx ML605 board

2013-05-06 Thread Sébastien Bourdeauducq


Hi,

could you use the same signal names as the other boards? e.g.
gpio_led - user_led, gpio_sw - user_btn, sys_clk/user_clk - 
clk[frequency] etc.


This makes porting designs across boards a bit easier.

Thanks,
Sebastien


On 05/06/2013 10:53 PM, Florent Kermarrec wrote:

Hi,

if you are interested by the kc705 file, it's here:

https://github.com/Florent-Kermarrec/mibuild/blob/master/mibuild/platforms/kc705.py
 (interfaces
names are derived from KC705's schematic).

It only contains the interfaces I'm using now.

Regards,

Florent


___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] Migen license - BSD

2013-04-16 Thread Sébastien Bourdeauducq


Hi,

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


Sebastien
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Fwd: [Help - MiGEN Tutorial]

2013-04-12 Thread Sébastien Bourdeauducq


On 04/12/2013 12:06 PM, Khobatha Setetemela wrote:

-I have confirmed that migensim.vpi installation path is visible in
python3 sys.path


Python's sys.path has nothing to do with the VPI module installation 
path. sys.path just where Python looks for Python modules. VPI modules 
are something completely different. You want to put migensim.vpi where 
Icarus Verilog looks for modules, e.g. /usr/lib/ivl or 
/usr/local/lib/ivl depending on your Icarus installation.


Sebastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

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

2013-04-12 Thread Sébastien Bourdeauducq


Committed, thanks Werner!

On 04/12/2013 10:38 PM, Werner Almesberger wrote:

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.)


___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] 1080p framebuffer on M1

2013-04-05 Thread Sébastien Bourdeauducq


On 04/03/2013 10:33 PM, Florent Kermarrec wrote:

do you plan to use tmu, pfpu on milkymist-ng? maybe recode it entirely
using migen?


Besides experimenting, my main plan for milkymist-ng is to use it in the 
video mixer, which will not need a PFPU or TMU. It will have a picture 
scaling core that has some in common with a TMU, though it is much simpler.


The picture scaler will be in Migen using the dataflow system, and the 
same should be used if one wants to design a TMU.


Sebastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Mibuild : Support for Altera quartus toolchain

2013-03-15 Thread Sébastien Bourdeauducq


Hi,

thanks for the files, I have merged them. Here are comments and things I 
changed:
* use Unix end-of-line characters (eg run dos2unix on the files after 
editing them on a Windows machine)
* renamed rst_level to rst_invert and made it boolean to be 
consistent with migen.fhdl.specials.Instance.{ClockPort, ResetPort}
* new-style Module API does not require you to form lists except for 
spanning multiple lines (this requirement only comes from the Python 
parser) so:

self.comb +=[self.cd.rst.eq(~rst_n)]
can be rewritten as
self.comb += self.cd.rst.eq(~rst_n)
* platform.request returns a new object if you don't specify one. 
Additionally, its second parameter defaults to None. So instead of writing:

rst_n = Signal()
platform.request(rst_name, None, rst_n)
you can write:
rst_n = platform.request(rst_name)
* removed unneeded Decimal, struct, Instance, SynthesisDirective, 
migen.fhdl.structure, migen.genlib.cdc and CRG imports from altera_quartus

* added reset inversion support to the Xilinx platform as well
* renamed led to user_led to be consistent with other platforms
* fixed minor indentation and style problems in de0nano
* can you send me headers to add to altera_quartus.py and de0nano.py 
that state that you are the main author of those files, and with 
copyright and license info?


Thanks,
Sebastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] EDID testbed

2013-03-13 Thread Sébastien Bourdeauducq


Hi,

Attached is a build script that does two things:
1) instantiates the new DDC/EDID core from milkymist-ng
2) blinks a LED using the DVI/HDMI pixel clock - basically this makes a 
xrandr-controlled LED blinker :)


It is useful for tracking down EDID problems on the video mixer (faster 
to synthesize than the whole SoC) and as an example of using Mibuild.


Sebastien
from migen.fhdl.structure import *
from migen.fhdl.module import Module
from mibuild.platforms import m1
from mibuild.crg import CRG

from milkymist.dvisampler.edid import EDID

class EDIDTester(EDID, CRG):
	def __init__(self):
		EDID.__init__(self)
		
		self.clk = Signal()
		self.data0_n = Signal()
		self.data1 = Signal()
		self.data2_n = Signal()

		self.clk50 = Signal()
		self.rst = Signal()
		self.led = Signal()

		self.cd_sys = ClockDomain(sys)
		self.cd_pix = ClockDomain(pix)

		self.comb += [
			self.cd_sys.clk.eq(self.clk50),
			self.cd_sys.rst.eq(self.rst),
			self.cd_pix.clk.eq(self.clk)
		]
		counter = Signal(23)
		self.comb += self.led.eq(counter[22])
		self.sync.pix += counter.eq(counter + 1)

dut = EDIDTester()
plat = m1.Platform()
plat.request(clk50, 0, dut.clk50)
plat.request(user_btn, 0, dut.rst)
plat.request(dvi_in, 0, dut)
plat.request(user_led, 0, dut.led)
plat.add_platform_command(NET \{clk}\ CLOCK_DEDICATED_ROUTE = FALSE;, clk=dut.clk)
plat.build_cmdline(dut, clock_domains=dut.get_clock_domains())
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] milkymist-ng + MMU images

2013-02-24 Thread Sébastien Bourdeauducq


Hi,

Here are some pre-built milkymist-ng images that have the MMU:
http://milkymist.org/mng_mmu-20130224.tar.bz2

I have not tested the MMU functionality, only that the system meets 
timing and still boots (without using the MMU).


I noticed two problems:
* synthesis fails with CFG_MMU_ENABLED and without CFG_DEBUG_ENABLED 
(and CFG_WATCHPOINTS + CFG_BREAKPOINTS).

* the CFG2 CSR is missing from the modified Binutils

The good news is that the resource utilization only increases by 3% of 
both the SLX45's slices and RAMB16BWERs.


Sébastien
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] [PATCH] Migen patches

2013-02-18 Thread Sébastien Bourdeauducq


On 02/18/2013 02:00 PM, Florent Kermarrec wrote:

The De0-Nano design is now using mibuild! (The altera_quartus platform
has still some missing functionalities but generates a valid fpga).


Great! Please submit a Mibuild patch when you feel it's ready. Thanks!

Sébastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] HDMI mixer extension protoboards

2013-02-18 Thread Sébastien Bourdeauducq


Hi,

Here are pictures of the assembled HDMI mixer extension:

https://twitter.com/Milkymist_Labs/status/303535201139703809/photo/1
https://twitter.com/Milkymist_Labs/status/303535092825989123/photo/1
https://twitter.com/Milkymist_Labs/status/303534968381001729/photo/1

I have a few extra PCBs, let me know if you want one. I don't have 
enough parts to populate all of them, though, so you may have to order 
some yourself and solder fine-pitch SMD.


Sébastien
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] [PATCH] Migen patches

2013-02-17 Thread Sébastien Bourdeauducq


Hi,

thanks for your patches, good to hear from you!

On 02/17/2013 05:24 PM, Florent Kermarrec wrote:

_bug:_
- in structure.py, assert(min max) should be assert(min = max) -- ex
: Signal(max=1)  (fhdl.patch)


Such a signal would only be capable of having the value 0 (remember that 
min is inclusive and max exclusive, as with Python ranges). If you 
want to describe a 0/1 signal, the correct value of max is 2.

Is there a practical purpose of such constant signals?


_addition:_
- remove signal reset if reset is initialized to None



--- a/migen/fhdl/tools.py
+++ b/migen/fhdl/tools.py
@@ -136,7 +136,7 @@ def is_variable(node):

 def insert_reset(rst, sl):
targets = list_targets(sl)
-   resetcode = [t.eq(t.reset) for t in sorted(targets, key=lambda x: 
x.huid)]
+   resetcode = [t.eq(t.reset) for t in sorted(targets, key=lambda x: 
x.huid) if t.reset != None]
return If(rst, *resetcode).Else(*sl)


OK, will apply.


 def value_bits_sign(v):
diff --git a/migen/fhdl/verilog.py b/migen/fhdl/verilog.py
index 0e0821c..ada00cf 100644
--- a/migen/fhdl/verilog.py
+++ b/migen/fhdl/verilog.py
@@ -192,7 +192,8 @@ def _printcomb(f, ns, display_run):
if display_run:
r += \t$display(\Running comb block # + str(n) + 
\);\n
for t in g[0]:
-   r += \t + ns.get_name(t) +  =  + 
_printexpr(ns, t.reset)[0] + ;\n
+   if t.reset is not None:
+   r += \t + ns.get_name(t) +  =  + 
_printexpr(ns, t.reset)[0] + ;\n


This code prevent latches, not optimizations (unless you are using a 
lousy synthesizer, which quite unfortunately can happen...). I'd rather 
treat None as 0 here.



@@ -281,7 +282,8 @@ def _printinit(f, ios, ns):
if signals:
r += initial begin\n
for s in sorted(signals, key=lambda x: x.huid):
-   r += \t + ns.get_name(s) +  =  + _printexpr(ns, s.reset)[0] 
+ ;\n
+   if s.reset is not None:
+   r += \t + ns.get_name(s) +  =  + _printexpr(ns, 
s.reset)[0] + ;\n
r += end\n\n
return r


Some FPGAs such as the Spartan-6 have a single bit for each FF that 
encodes both the bitstream load reset value and the value taken when the 
reset pin is asserted. When the synthesizer can extract a reset signal 
from the logic driving the FF but the corresponding reset value does not 
match the bitstream load value (which is set by such an initial block), 
then the reset pin becomes unusable. I think it makes sense to have the 
possibility not to block this reset extraction optimization, so I will 
apply this change.



- add we_granularity parameter to Wishbone SRAM (wishbone.patch):
On altera cyclone 2, we_granularity is not supported by M4K memory blocks.


It would be much better to implement a Fragment transform function that 
breaks down any memory that uses we_granularity into smaller memories 
that are we_granularity bits wide each. This way, the problem would be 
solved for all memories, not only the Wishbone SRAM.


Of course, the best option would be to fix Quartus so that it does this 
transform itself from the Verilog code...



- add Wishbone ROM class (wishbone.patch):
In my case, it is used to store LM32 instructions in M4K memory blocks.


Please merge it with SRAM (and use another name? StaticMem?) since most 
of the code can be shared.



With some others small modifications (addition of a wishbone size
adapter and addition of 1 phase support to the ASMICON) the simplified
version of milkymist-ng is now working on the De0-Nano :)  :
http://github.com/Florent-Kermarrec/Soc-De0Nano


Great! Are you planning to switch it to Mibuild 
[http://milkymist.org/3/migen-tutorial.pdf]? I think it makes a lot of 
sense to have Mibuild support for simple boards like DE0.


Regards,
Sébastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] [PATCH] Migen patches

2013-02-17 Thread Sébastien Bourdeauducq


On 02/17/2013 05:57 PM, Sébastien Bourdeauducq wrote:

--- a/migen/fhdl/tools.py
+++ b/migen/fhdl/tools.py
@@ -136,7 +136,7 @@ def is_variable(node):

 def insert_reset(rst, sl):
 targets = list_targets(sl)
-resetcode = [t.eq(t.reset) for t in sorted(targets, key=lambda x:
x.huid)]
+resetcode = [t.eq(t.reset) for t in sorted(targets, key=lambda x:
x.huid) if t.reset != None]
 return If(rst, *resetcode).Else(*sl)


OK, will apply.


Hmm, actually no - the reset would still act as active-low clock enable 
for those signals with reset=None, which I don't like.


I see two solutions:
1) extract the statements that assign to reset=None signals from the 
list, and put them after the If(rst, ...).
This is a bit complex considering that you have to take into account 
assignments inside conditional statements etc.
2) support reset-less clock domains and let the user put assignments 
to signals that should not have a reset into such a domain.


Considering that reset-less signals are usually rare (so the complexity 
of #1 is less justified), and that clock domains with flexible reset 
options are also useful for other purposes (such as a design that only 
uses the bitstream load reset values for initializing the FFs) I'm in 
favor of #2.


Sébastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] [PATCH] Migen patches

2013-02-17 Thread Sébastien Bourdeauducq


On 02/17/2013 09:30 PM, Florent Kermarrec wrote:

In fact the issue I had was in the ASMICON/bankmachine.py l45: self.tag = 
Signal(max=self.nslots), with self.nslots=1.
I will have a look at the generated code to see what is generated with migen.


Hmm, indeed, ASMI isn't really meant to be used with a single slot...


It would be much better to implement a Fragment transform function
that breaks down any memory that uses we_granularity into smaller
memories that are we_granularity bits wide each. This way, the
problem would be solved for all memories, not only the Wishbone SRAM.


I think it won't be exactly the same. I have the issue only with the
Cyclone 2, the Cyclone IV is Ok. On the cyclone 2, the M4K does not
support byte enable if read is done continuously. My modification was
only a quick work-around for that. With your solution I will use 4x more
M4K and it will probably won't feet in my fpga.


M4K memory blocks can be configured as 512x8 
[http://www.altera.com/literature/hb/cyc2/cyc2_cii51008.pdf].
With the one memory per byte solution, the SRAM granularity is four 
M4K blocks in 512x8 configuration, i.e. the SRAM size has to be a 
multiple of 2KB. This doesn't sound like a difficult constraint.


Sébastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] Fwd: Patch - add CFG_* instructions to FPGA description files

2013-02-15 Thread Sébastien Bourdeauducq

 Original Message 
Subject: Patch - add CFG_* instructions to FPGA description files
Date: Fri, 15 Feb 2013 18:42:33 +0100
From: Sébastien Bourdeauducq sebastien.bourdeaud...@lekernel.net
To: urjtag-developm...@lists.sourceforge.net

Hi,

the attached patch adds the CFG_IN and CFG_OUT instructions to the
Spartan 3/6 and Virtex 4 description files. This makes it unnecessary to
define those instructions manually before using pld load. Please apply.

Sébastien

add_fpga_config_instructions.diff.bz2
Description: BZip2 compressed data
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Multiplexing two bidirectional data buses

2013-02-14 Thread Sébastien Bourdeauducq

Hi,

I'd recommend you focus your efforts on milkymist-ng
(https://github.com/milkymist/milkymist-ng /
http://milkymist.org/3/migen.html). Since PSRAM is slow, I don't think
you could go much further than CPU + framebuffer - both are working
today on -ng.

Sébastien

On 02/08/2013 09:43 PM, Fernand LONE SANG wrote:

Hi folks,

In my spare time, I am trying to port Milkymist SoC on the Digilent
Nexys 3 board. Unfortunately,
this development board does not support DRAM and has a Cellular RAM
instead. I am currently
developing a module to drive this Cellular RAM and I am facing to some
issues. I wish someone
on this mailing-list could give me some hint to solve them.

On the Nexys 3 board, both norflash and Cellular RAM are connected to
a common bidirectional
data bus. Data are forwarded either to the norflash or the Cellular
RAM by selecting the right chip
using a chip select signal. To multiplex signal coming from the module
driving the norflash and the
module driving the Cellular RAM, I have coded a small bus switch.
The code is attached to this
mail. Please note that I am using inout ports on the module.

After I run XST, and when I open the ChipscopePro inserter, I see that
XST has removed the
module that drives the norflash, the Cellular RAM and the bus
switch. I have these warnings:

WARNING:Xst:2042 - Unit [...] : [x] internal tristates are replaced by
logic (pull-up yes)
WARNING:Xst:1906 - Unit [...] is merged (output ports from interface
drive multi-sources)

This topic has been discussed few years ago on Xilinx forum
(http://forums.xilinx.com/t5/Synthesis/problem-of-quot-INOUT-quot-use-quot-internal-tristates-are/td-p/122342)
and last year on Milkymist IRC channel
(http://en.qi-hardware.com/mmlogs/milkymist_2012-02-01.log.html)
and it seems that a solution to my problem is to change each inout
port, except ports from the top
module, to three equivalent signals (in, out, oe), right ? As I want
to keep my code for the Nexys 3
as close as possible to the code of Milkymist, so I wish someone
could suggest me a solution
(if an alternative exists) in which I do not have to modify the code
of the norflash core in Milkymist
to have the data port (inout) modified to its two equivalent signals
(oe is already available).

Any hint on how i can achieve this ?

Thanks,

--
Fernand

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] Tutorial: An introduction to Migen

2013-02-09 Thread Sébastien Bourdeauducq


Hi,

I have written an intro tutorial to FPGA design with Migen, for people 
with some knowledge of Unix commands, Python and logic design:

http://milkymist.org/3/migen-tutorial.pdf

(LaTeX sources here: https://github.com/milkymist/migen-extradoc)

Let me know how it goes, all feedback welcome.

Sébastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] 2-channel HDMI/DVI prototype mixer extension for M1

2013-02-06 Thread Sébastien Bourdeauducq


Hi,

Thanks for your suggestion, but I'm trying to create the most simple 
device possible now. Also, I already have the parts for the other 
solution (and don't overestimate Farnell Germany, some - paid - items 
from my October 24th order are still missing).


Sébastien


On 02/06/2013 12:37 AM, Ed Leckie wrote:

Hi Sebastien,

What about using a simple sigma delta adc?
It only requires a comparator and RC external to the FPGA, and only utilizes 2 
IOs which is a similar cost to your implementation.
http://www.latticesemi.com/products/intellectualproperty/referencedesigns/simplesigmadeltaadc.cfm

This allows for external control voltages too!

Cheers,
Ed.


___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] 2-channel HDMI/DVI prototype mixer extension for M1

2013-02-05 Thread Sébastien Bourdeauducq


Hi,

I'm done with a first, not fully verified, layout for that 2-channel 
HDMI/DVI board for M1 
(http://lists.milkymist.org/pipermail/devel-milkymist.org/2012-October/003156.html). 
Comments/review welcome, will send to fab soon!


Schematics:
http://milkymist.org/vmixext-5fev/schematics/vmixext.pdf
http://milkymist.org/vmixext-5fev/schematics/channel.pdf

Layout:
http://milkymist.org/vmixext-5fev/gerbers/vmixext.png

All design files:
http://milkymist.org/vmixext-5fev/

Sébastien
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] LM32 LLVM broken

2013-01-09 Thread Sébastien Bourdeauducq


On 01/07/2013 12:20 AM, JP Bonn wrote:

The latest updates did include some minor tblgen related changes but 
everything's working for me.  I can try doing a clean rebuild of everything 
tomorrow.


Strangely enough, this bug manifests itself only when building with 
cmake. The compilation goes through when using autoconf.


S.

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] xulamist (milkymist with 16 bit sdram interface)

2013-01-05 Thread Sébastien Bourdeauducq

Since that SDRAM part on that board might operate at up to 200MHz (check
which speed grade you have), I'd recommend you use milkymist-ng and its
memory controller (ASMIcon) with a 1:2 frequency ratio, e.g. run the SoC
at 83MHz and the SDRAM at 166MHz.

http://www.winbond.com/NR/rdonlyres/16898431-2772-4CEA-8474-7E4AA85F/0/W9825G6JH.pdf
https://github.com/milkymist/milkymist-ng

You will basically need to:
* modify the PHY so that the data serialization ratio becomes 2 (instead
of currently 4 for DDR).

* adapt the clocking accordingly.
* check the timing and other ASMIcon parameters. You have 2 phases and
32-bit data.
* modify the initialization sequence in the BIOS to send the SDR (not
DDR) sequence and set burst length to 2.

Sébastien

On 01/05/2013 06:22 AM, Troy Benjegerdes wrote:

I've got an XESS Xula2 board ( http://www.xess.com/prods/prod055.php )
and eventually I'm planning on doing a ghetto resistor VGA DAC (like
at
http://devbisme.webfactional.com/blogs/devbisme/2011/06/02/simple-vga-interface-xula-fpga-board
)

But first, I need to figure out how to convert from the current 32
bit SDRAM interface to the 16 bit interface on the board. There's
even an SDRAM controller in vhdl
https://github.com/xesscorp/XuLA2/blob/master/FPGA/XuLA_lib/SdramCntl.vhd

So my question is: What's easier/better? Try to use the vhdl version,
or switch the existing milkymist controller to 16 bit? What verilog file
should I be looking in to make the changes?

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] Fwd: UBB-JTAG: proof of concept with M1

2013-01-04 Thread Sébastien Bourdeauducq





 Original Message 
Subject: UBB-JTAG: proof of concept with M1
Date: Fri, 4 Jan 2013 16:02:58 -0300
From: Werner Almesberger wer...@almesberger.net
Reply-To: English Qi Hardware mailing list - support, developers, use 
cases and fun discuss...@lists.en.qi-hardware.com

To: discuss...@lists.en.qi-hardware.com

No breakout board could be considered universal if it doesn't also
support JTAG. I've now made a proof of concept implementation that
demonstrates this on the example of the Milkymist One.

All the protocol handling is done by UrJTAG. For simplicity, I use
the gpio cable driver, which accesses GPIOs through
/sys/class/gpio/...  and is therefore not exactly a speed demon.

This is what the whole setup looks like:

http://downloads.qi-hardware.com/people/werner/ubb/jtag/ubb-jtag-m1-all.jpg

Since the JTAG interface of Milkymist One runs at 2.5 V while the
Ben uses 3.3 V, the adapter has a few voltage dividers acting as
level shifters:

http://downloads.qi-hardware.com/people/werner/ubb/jtag/ubb-jtag-m1-card.jpg

Since I don't have a mating connector for J6 (2 mm pitch) at
home, I improvised by making individual cables with receptables
for 2.54 mm headers:

http://downloads.qi-hardware.com/people/werner/ubb/jtag/ubb-jtag-m1-j6.jpg

A README with all the gory details (there a few quirks), a
schematic drawing, and cut-out labels for the wires can be found
here:
http://projects.qi-hardware.com/index.php/p/ben-blinkenlights/source/tree/master/ubb-jtag

- Werner

___
Qi Hardware Discussion List
Mail to list (members only): discuss...@lists.en.qi-hardware.com
Subscribe or Unsubscribe: 
http://lists.en.qi-hardware.com/mailman/listinfo/discussion



___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] small questions

2012-12-18 Thread Sébastien Bourdeauducq


Hi,

On 12/14/2012 06:48 PM, Błażej Krajczewski wrote:

Could you tell me whether this box has possibility to programmed 10-15
presets and play them on f.e. 1h loop?


Yes, the simple performance mode can be configured to do that.


How Milkymist cooparate on small videomapping projections? If I able to
implement some mask of object to reduce range of animation? Or send such
mask via video in?


There is no software for doing this, even though the hardware would be 
capable of it. Of course, if you feel like diving into the code, you 
could implement that yourself.


Sébastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Milky Mist at 29C3?

2012-12-13 Thread Sébastien Bourdeauducq


Hi,

thanks for getting in touch. Obviously I'll be at http://ehsm.eu all the 
time, but maybe someone else on the list who might go to 29C3 could do it.


Sébastien


On 12/13/2012 12:36 PM, Jens Ohlig wrote:

Hey there,

we're organizing an assembly (
https://events.ccc.de/congress/2012/wiki/Assemblies ) at the 29th Chaos
Communication Congress in Hamburg, Germany. Our assembly will be all
about mass collaboration, Open Access, Open Data, Open Whatever. Would
you like to join? Would you be interested in giving a short presentation?

Would be nice to hear from you soon :)

Cheers,
Jens Ohlig

--
Software developer Wikidata
Wikimedia Deutschland e.V. | Obentrautstraße 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de http://wikimedia.de/

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt
für Körperschaften I Berlin, Steuernummer 27/681/51985.



___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] [PATCH 00/11] lm32 testbenches

2012-11-14 Thread Sébastien Bourdeauducq


Hi Michael,

thank you for the patches. I have applied them to both the legacy SoC 
and to -ng without the Verilog test bench.


Sébastien

On 11/12/2012 07:36 PM, Michael Walle wrote:

This patchset adds support for simulating the LatticeMico32 core in Icarus
Verilog. Additionally, various cleanups are included :)



___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Debugging LM32 embedded software

2012-10-23 Thread Sébastien Bourdeauducq


Hi,

On 10/23/2012 12:31 PM, Lucas Russo wrote:

Is there a way to debug an embedded LM32 software (no OS), by means
of JTAG and GDB? If there is, how to integrate them in a custom open design?


We're not using JTAG anymore (due to problems with OpenOCD). Instead 
Michael developed a system that uses the UART alone, and consists of a 
debug ROM that implements the GDB protocol. Sending a BREAK character on 
the UART cause a hardware jump to that ROM which takes over 
communications and can read/write memory, set breakpoints, etc.


https://github.com/milkymist/milkymist/tree/master/software/gdbstub
http://milkymist.org/wiki/index.php?title=Using_GDB_in-system_debugger

Sébastien

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] HDMI/DVI mixer extension for M1 - draft schematics

2012-10-10 Thread Sébastien Bourdeauducq

Hi,

I've been working on a M1 daughterboard that can turn it into a simple
video mixer. It has two HDMI ports, one crossfade linear
potentiometer, and one fade to black knob.

Draft schematics are here:
http://milkymist.org/vmixext-20121010.pdf

Connection with the M1
==
Power and video streams are via the expansion port J21. The design is
compatible with all M1 revisions, including the very first six R1
prototypes. The two 5V pins that have been added in R2/R3 are not used,
instead, this voltage is supplied by the HDMI source.

I/Os are severely lacking on this port, thus:
1) TMDS needs to be converted to a single-ended I/O standard.
2) The HDMI HPD signal cannot be controlled.
3) The connection of the potentiometers is to be done using the M1's
memory card pins.

TMDS to LVCMOS conversion
=
Since there are no existing chips that can do this, we use a LVDS to
LVCMOS converter instead and tweak the voltage levels to make the
signals palatable to all devices involved.
TMDS requires a 50 ohm termination to 3.3V. It is not allowed to
terminate it to another DC voltage as it might cause some monitor
detection features to fail [1].
Since the encoding of the TMDS data makes the signal DC-balanced, we can
use a high-impedance AC coupling after the 50 ohm termination. The DC
bias to the 1.2V LVDS offset voltage is provided by a 8.2K/4.7K divider
connected to the 3.3V supply.
TMDS has up to 600mV single-ended swing [2], higher than the 400mV
maximum of LVDS. However, the MAX9121 chip can tolerate up to 1V. Using
a series resistor to reduce the swing as suggested in [3] would not have
been easily possible as the equivalent resistance of the divider network
is too high: the input capacitance of the chip combined with the high
series resistor value would quickly ruin the signal edges.

Now let's see if this works :)

Potentiometers
==
Simple circuit here, the FPGA generates a rising edge on pin 4 and the
charge times of the capacitors through R59+P1/R60+P2 is measured after
thresholding by the Schmitt triggers U3/U4.

Limitations
===
HDMI is characterized by massive and unpredictable clock skew, and
recovering the data requires a phase detector [4]. Since the hard
phase detector can only be used with differential signals, we'll need to
reimplement it with 2X oversampling of the signal using ISERDES. This
oversampling can occur at a maximum of 945MHz due to the slowness of the
S6 I/O clocking, which will limit the pixel clock to 47.25MHz. A
resolution of 800x600 60Hz 24bpp should remain possible, however.
Another limitation is that, still due to the lack of I/O, the HPD signal
cannot be controlled. This can cause the video source to attempt DDC
transfers while the gateware is not ready, and finally give up and
disable the port. Connecting or enabling the video source only after the
M1 is ready should work reliably, though.

Next steps
==
This add-on board should be good for prototyping HDMI and a simple video
mixer. Later, we may want to integrate those ports on the same board as
the FPGA, and get rid of the I/O hacks (which along with the improved
memory bandwidth in milkymist-ng should enable HD resolutions like 720p60).

Comments welcome.

Thanks,
Sébastien

[1] http://en.wikipedia.org/wiki/TMDS
[2] http://www.ddwg.org/lib/dvi_10.pdf p.36
[3] http://lekernel.net/diff_convert.pdf fig. 8
[4]
http://www.xilinx.com/support/documentation/application_notes/xapp495_S6TMDS_Video_Interface.pdf

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] 3 new EHSM speakers announced - save 15E by registering before Oct 1st

2012-09-27 Thread Sébastien Bourdeauducq


Hi,

quick update on the EHSM conference in Berlin, we recently announced 
three new speakers:


* Harald Welte will present the Osmocom project he founded. In 
particular, there will be OsmocomBB, a free software GSM stack evolved 
enough to actually make phone calls and send SMS (plus all the possible 
explorations of the GSM system), and OsmoSDR, a small-size, low-cost 
software defined radio device.
* Last year, CERN launched a new open hardware license. Evangelia 
Gousiou will tell you about this endeavour which was created to govern 
the use, copying, modification and distribution of hardware design 
documentation and the manufacture and distribution of products in the 
spirit of knowledge and technology dissemination.
For the more technically-minded, she will also present the White Rabbit, 
an open hardware and software Ethernet-based system to synchronize ~1000 
nodes with sub-nanosecond accuracy over fiber and copper lengths of up 
to 10 km.
* Nadania Idriss is a California transplant who founded Berlin Glas e.V. 
in 2009. The studio is the first in Berlin to offer hot glass for 
artists and the general public. Check out her short presentation to 
learn how you too can work with this material! (glass blowing etc.)


You can save 15E/$20 if you register before Oct 1st.

See http://ehsm.eu for all details, and we're still looking for 
presentation proposals!


Sébastien
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] improved Migen signal namer

2012-09-11 Thread Sébastien Bourdeauducq


def gen_list(n):
s = [Signal() for i in range(n)]
return s

def gen_2list(n):
s = [Signal(BV(2)) for i in range(n)]
return s

class Foo:
def __init__(self):
la = gen_list(3)
lb = gen_2list(2)
self.sigs = la + lb

class Bar:
def __init__(self):
self.sigs = gen_list(2)

a = [Bar() for x in range(3)]
b = [Foo() for x in range(3)]
c = b
b = [Bar() for x in range(2)]
output = Signal()

=== old signal namer

reg foo0_la___main__;
reg [1:0] foo0_lb___main__;
reg [1:0] foo0_lb___main___1;
reg foo1_la___main__;
reg foo0_la___main___1;
reg bar3_sigs___main__;
reg bar4_sigs___main__;
reg bar4_sigs___main___1;
wire output;
reg bar0_sigs___main__;
reg bar1_sigs___main__;
reg bar1_sigs___main___1;
reg bar2_sigs___main__;
reg bar2_sigs___main___1;
reg bar0_sigs___main___1;
reg foo1_la___main___1;
reg foo1_la___main___2;
reg [1:0] foo1_lb___main__;
reg bar3_sigs___main___1;
reg [1:0] foo1_lb___main___1;
reg foo2_la___main__;
reg foo2_la___main___1;
reg foo2_la___main___2;
reg [1:0] foo2_lb___main__;
reg [1:0] foo2_lb___main___1;
reg foo0_la___main___2;

=== new signal namer

reg a_bar0_s0;
reg a_bar0_s1;
reg a_bar1_s0;
reg a_bar1_s1;
reg a_bar2_s0;
reg a_bar2_s1;
reg b_foo0_la_s0;
reg b_foo0_la_s1;
reg b_foo0_la_s2;
reg [1:0] b_foo0_lb_s0;
reg [1:0] b_foo0_lb_s1;
reg b_foo1_la_s0;
reg b_foo1_la_s1;
reg b_foo1_la_s2;
reg [1:0] b_foo1_lb_s0;
reg [1:0] b_foo1_lb_s1;
reg b_foo2_la_s0;
reg b_foo2_la_s1;
reg b_foo2_la_s2;
reg [1:0] b_foo2_lb_s0;
reg [1:0] b_foo2_lb_s1;
reg b_bar0_s0;
reg b_bar0_s1;
reg b_bar1_s0;
reg b_bar1_s1;
wire output;
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] RFA: LM32: Fix building libgcc

2012-09-04 Thread Sébastien Bourdeauducq


Hi,

sorry for the delayed answer, I'm traveling and have limited time and 
access to internet.


The first part of your patch (...SYMBOL_REF_FLAGS (x) |= 
SYMBOL_FLAG_SMALL;) actually resolves the infinite recursion problem I 
encountered. Now I get the same ICE in var-tracking.c as you.


I'm however worried that this first part might break the generated code 
(I'm not 100% sure, but it seems related enough). In one example, which 
loads the address of a string into r1, instead of having the correct 
instruction sequence:

   c:   78 01 00 00 mvhi r1,0x0
  14:   38 21 00 00 ori r1,r1,0x0
with the two relocations:
000c  0504 R_LM32_HI16      .rodata.str1.4 + 0
0014  0505 R_LM32_LO16      .rodata.str1.4 + 0

the new GCC generates:
   c:   2b 41 00 00 lw r1,0
with one relocation:
000c  0606 R_LM32_GPREL16   .rodata.cst4 + 0

You can reproduce the problem with a simple source code:
void foo(void)
{
  bar(blah);
}

This also causes the linker to fail with a cryptic warning: internal 
error: dangerous error message.


Sébastien


On 08/28/2012 12:45 PM, nick clifton wrote:

Hi Sébastien,


is that with SVN head?


Yes...


The problem we're having is actually that
infinite recursion segfault, and it happens very soon (libgcc configure
cannot even complete).


Not to me...


are you building on 32-bit x86?


Yes...


The only local patch that I have applied is my lm32 one.  I have
attached another copy of it here.  Perhaps I made a fix and forgot to
mention it ?  (That would not surprise me, I am juggling several
different local builds at the moment).

Cheers
   Nick





___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] Fwd: RFA: LM32: Fix building libgcc

2012-08-17 Thread Sébastien Bourdeauducq

This looks better.

 Original Message 
Subject: RFA: LM32: Fix building libgcc
Date: Fri, 17 Aug 2012 11:21:32 +0100
From: Nick Clifton ni...@redhat.com
To: sebast...@milkymist.org
CC: gcc-patc...@gcc.gnu.org

Hi Sebastien,

  Currently the lm32-elf target fails to configure libgcc because of a
  seg-fault whilst running the configuration checks:

configure:3794:  lm32-elf/gcc/xgcc [...] conftest.c
xgcc: internal compiler error: Segmentation fault (program cc1)

  GCC goes into an infinite loop trying to generate a valid return
  instruction.  The problem is the epilogue and return patterns are
  misnamed.  The return is really a simple_return and the epilogue is
  really the (complex) return.  Thus the patch below fixes the problem
  and allows the libgcc library to be configured and built.

  OK to apply ?

Cheers
  Nick

gcc/ChangeLog
2012-08-17  Nick Clifton  ni...@redhat.com

* config/lm32/lm32.md (return): Rename to simple_return.
(epilogue): Rename to return.

Index: gcc/config/lm32/lm32.md
===
--- gcc/config/lm32/lm32.md (revision 190466)
+++ gcc/config/lm32/lm32.md (working copy)
@@ -636,13 +636,14 @@
   [(set_attr type uibranch)]
 )

-(define_insn return
-  [(return)]
+(define_insn simple_return
+  [(simple_return)]
   lm32_can_use_return ()
   ret
   [(set_attr type uibranch)]
 )
@@ -961,7 +962,7 @@
   DONE;
 })

-(define_expand epilogue
+(define_expand return
   [(return)]

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] some quick news

2012-08-12 Thread Sébastien Bourdeauducq


1. Migen/milkymist-ng progress
==

The first dataflow designs are now working correctly on hardware, 
including dataflow access to system SDRAM via the new ASMIcon controller.


ASMIcon provides several features to improve memory performance:
* it runs the SDRAM at a multiple of the system frequency (2x with the 
DDR on the Milkymist One)
* it is capable of generating and issuing multiple non-conflicting SDRAM 
commands per clock cycle (e.g. reading from one bank and precharging 
another)
* it supports a wide transaction issue (all ports can issue a new 
transaction in a clock cycle)
* it is capable of reordering issued transactions to maximize the page 
hit rate and minimize data bus wait cycles due to read/write turnaround.


The framebuffer example features multiple in-flight transactions to 
fetch pixel data from system memory with support for out-of-order 
completion, and should be able to support high resolutions and color 
depths with minimal on-chip buffering.


Some documentation about the architecture of the framebuffer core is 
part of the Migen documentation:

http://milkymist.org/3/migen.pdf

Try it by compiling and running milkymist-ng:
https://github.com/milkymist/milkymist-ng
(Enable the framebuffer with mw 0xe0002800 1 - there is no software 
support yet)


2. Website redesign
===

I have redesigned the http://milkymist.org website and reworked the 
content a bit. The new design is simpler and lighter and makes some room 
for future products.


3. FPGAworld


I will be at FPGAworld on September 4th in Stockholm, presenting Migen. 
Conference programme is there:

http://fpgaworld.com/conference_stockholm.shtml
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Migen embedded blocks in Verilog

2012-07-21 Thread Sébastien Bourdeauducq


On 07/20/2012 12:31 PM, Florent Kermarrec wrote:

- I have to code an FSM, but keep fine control of others parts of my code,
   let's use migen only for my FSM!


Can you give an explicit example of how you'd do this?

As I understand it, the Migen code for the FSM has to assign to external 
(non-Migen) Verilog signals at some point, and it's not clear to me how 
it can be done with your current code.


e.g.

module foo();
reg [2:0] control_word;
[... some datapath that is controlled with control_word ...]
[-
FSM in Migen that writes to control_word... but how do you do this?
-]
endmodule

Thanks,
Sébastien
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

[Milkymist-devel] Fwd: Re: [PATCH] [LM32] Fix lm32-elf-gcc build error by remove unnecessary constant legitimate check.

 Original Message 
Subject: Re: [PATCH] [LM32] Fix lm32-elf-gcc build error by remove 
unnecessary constant legitimate check.

Date: Wed, 11 Jul 2012 22:04:11 -0400 (EDT)
From: Hans-Peter Nilsson h...@bitrange.com
To: Jia Liu pro...@gmail.com
CC: gcc-patc...@gcc.gnu.org, Sébastien Bourdeauducq 
sebast...@milkymist.org

On Tue, 10 Jul 2012, Jia Liu wrote:

Hi all,

When I build lm32-elf-gcc, it failed at libgcc configure due to
lm32-elf-cc1 segment fault when compile conftest.c:

void bar ();
void clean (int *);
void foo ()
{
  int i __attribute__ ((cleanup (clean)));
  bar();
}

Then I find lm32_legitimate_constant_p return false too much times, it
shouldn't like this, I think.

And I find the movsi pattern has handle the pic and reloc_operand, but
lm32_legitimate_constant_p
handle them again, so, I think maybe it is unnecessary.

The movsi pattern really is expected to handle it; the
TARGET_LEGITIMATE_CONSTANT_P (i.e. lm32_legitimate_constant_p)
is for immediate operands to *other* insns.  The movsi pattern
is expected to handle the rest.  The correct solution is
elsewhere.

When I remove the unnecessary constant legitimate check, lm32-elf-gcc
is built OK.

But most likely will fail to generate correct code for some
source codes for which it worked before.

A patch like this needs a full test-suite run anyway.

(Not an approver-review.)

brgds, H-P

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Compilation migen


Hi,

this file is provided by Icarus Verilog. Please see the Installing the 
VPI module section of the Migen documentation:

http://milkymist.org/Migen.pdf

Also make sure to build Icarus Verilog from source (using a fresh 
checkout from the official repository) because releases contain a bug 
that prevents the Migen plug-in from working.


Sébastien


On 07/11/2012 06:16 PM, Pierre BARRE wrote:

Hi,
When I tried to compile migen with its Makefile he answer :
main.c : 9:10: fatal error : 'vpi_user.h' file not found
where is it ?



___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Compilation migen


On 07/12/2012 04:32 PM, Pierre BARRE wrote:

PS : votre nom est français, parlez-vous français ?


yes, but this mailing list is English speaking.

By the way, may I ask what you are planning to do with Migen? (just curious)

Sébastien
___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Compilation migen


On 07/12/2012 07:22 PM, Pierre BARRE wrote:

I have a new idea for a paralel additionner, may be i will test this in
a fpga.


I don't think you can easily beat the carry chains...

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Re: [Milkymist-devel] Compilation migen