m-labs / misoc Goto Github PK

m-labs/migen#30

Copied from the pdq directory as requested. I have since also ran it in a python 3.5 environment and got the same error. Could you also please clarify which readme you updated? Looking at the history for the misoc and pdq readme files I don't see any recent commits.

As I mentioned in pdq issue 10, I am running into issues trying to compile the gateware. I was instructed to install ISE Webpack, but I do not believe that to be the problem. I have ISE Design Suite 14.7 with the free webpack license installed. The error comes in when attempting to install misoc (migen installs just fine).

I ran the following commands:
conda update conda
pip install -e git://github.com/m-labs/misoc.git#egg=misoc

That gives the following command line output:

(C:\ProgramData\Anaconda3) C:\Users\rabi\Documents\pdq-master>conda update conda

Fetching package metadata .................
Solving package specifications: .

# All requested packages already installed.
# packages in environment at C:\ProgramData\Anaconda3:
#
conda 4.3.22 py36_0 conda-forge/label/m
ain

(C:\ProgramData\Anaconda3) C:\Users\rabi\Documents\pdq-master>pip install -e git
://github.com/m-labs/misoc.git#egg=misoc
Obtaining misoc from git+git://github.com/m-labs/misoc.git#egg=misoc
Updating c:\users\rabi\documents\pdq-master\src\misoc clone
Requirement already satisfied: pyserial in c:\programdata\anaconda3\lib\site-pac
kages (from misoc)
Collecting asyncserial (from misoc)
Could not find a version that satisfies the requirement asyncserial (from miso
c) (from versions: )
No matching distribution found for asyncserial (from misoc)

• with tx_irq_condition="empty", we have possible gaps between transfers but we are able to reduce number of irqs on large transmissions by a factor of up to tx_fifo_depth.
• with tx_irq_condition="non-full", we avoid gaps (since we are able to always ensure there is something in the fifo) but for large transmissions (> to tx_fifo_depth) we then generate one interrupt per character.

An "almost-empty" solution should have both advantages without costing too much ressources. It has to be evaluated.

This makes most flash functions unusable.

And do not call the WB bridge "frontend".

****** Vivado v2015.1 (64-bit)
  **** SW Build 1215546 on Mon Apr 27 19:22:08 MDT 2015
  **** IP Build 1209967 on Tue Apr 21 11:39:20 MDT 2015
    ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.

source top.tcl
# add_files C:\Python34\lib\site-packages\misoc-1.0-py3.4.egg\misoc\cores\lm32\v
erilog\submodule\rtl\lm32_icache.v
ERROR: [Vivado 12-172] File or Directory 'C:Python34libsite-packagesmisoc-1.0-py
tllm32_icache.v' does not existmodule
INFO: [Common 17-206] Exiting Vivado at Sun Oct 18 22:10:53 2015...

and probably the same issue than #23

'\r\n' works "out the box" with a lot more serial terminal programs (minicom, putty, etc).

See comment on commit 9f74894

c.f. m-labs/artiq#800 for context

Hello,

I was able to successfully build the blinkie project for the Spartan6 FPGA with Xilinx ISE14.7 (64-Bit) under CentOS6.5.

However, if I try to only synthesize the referenced lm32 core (lm32_top as top level) for a Virtex5, the lm32_config.v produces an ERROR:
"lm32_config.v" line 187 expecting 'EOF', found 'function'

Interestingly, a similiar problem seems to appear in the synthesis log of the blinkie project, but only as a WARNING:
"lm32_config.v" Line 187: Root scope declaration is not allowed in verilog 95/2K mode

I tried the same using Xilinx Vivado 2014.2 (64-Bit) for an Artix7.
Here I get the message >"lm32_config.v" Line 187: Root scope declaration is not allowed in verilog 95/2K mode< again, but this time as ERROR message.

Any idea, how to fix this properly?

As far as I can tell, migen.actorlib is no longer a thing?

https://github.com/m-labs/misoc/blob/master/misoc/cores/framebuffer/format.py#L6

I forgot to init the submodules when cloning misoc. Running python setup.py install worked fine but I later got an error like the following when trying to build;

 CC       crc16.o                                                                                                                                                                                        [7700/9787]
 CC       crc32.o
 CC       console.o
 CC       system.o
 CC       id.o
 CC       uart.o
 CC       time.o
 CC       qsort.o
 CC       strtod.o
 CC       spiflash.o
 CC       vsnprintf.o
 AR       libbase.a
 CC       vsnprintf-nofloat.o
 AR       libbase-nofloat.a
make: Leaving directory `/usr/local/google/home/tansell/foss/timvideos/hdmi2usb/i2cslave/misoc_i2csoc_pipistrello_i2c/software/libbase'
make: Entering directory `/usr/local/google/home/tansell/foss/timvideos/hdmi2usb/i2cslave/misoc_i2csoc_pipistrello_i2c/software/libcompiler_rt'
make: *** No rule to make target `divsi3.o', needed by `libcompiler_rt.a'.  Stop.
make: Leaving directory `/usr/local/google/home/tansell/foss/timvideos/hdmi2usb/i2cslave/misoc_i2csoc_pipistrello_i2c/software/libcompiler_rt'
Traceback (most recent call last):
  File "/usr/local/google/home/tansell/foss/timvideos/hdmi2usb/i2cslave/build/lib/python3.4/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/google/home/tansell/foss/timvideos/hdmi2usb/i2cslave/build/lib/python3.4/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/local/google/home/tansell/foss/timvideos/hdmi2usb/i2cslave/i2cslave/targets/pipistrello_i2c.py", line 403, in <module>
    main()
  File "/usr/local/google/home/tansell/foss/timvideos/hdmi2usb/i2cslave/i2cslave/targets/pipistrello_i2c.py", line 399, in main
    builder.build()
  File "/usr/local/google/home/tansell/foss/timvideos/hdmi2usb/i2cslave/build/lib/python3.4/site-packages/misoc-0.1-py3.4.egg/misoc/integration/builder.py", line 133, in build
    self._generate_software()
  File "/usr/local/google/home/tansell/foss/timvideos/hdmi2usb/i2cslave/build/lib/python3.4/site-packages/misoc-0.1-py3.4.egg/misoc/integration/builder.py", line 110, in _generate_software
    subprocess.check_call(["make", "-C", dst_dir])
  File "/usr/local/google/home/tansell/foss/timvideos/hdmi2usb/i2cslave/build/lib/python3.4/subprocess.py", line 561, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['make', '-C', '/usr/local/google/home/tansell/foss/timvideos/hdmi2usb/i2cslave/misoc_i2csoc_pipistrello_i2c/software/libcompiler_rt']' returned non-zero exit status 2
tansell@tansell-z620-l2:~/foss/timvideos/hdmi2usb/i2cslave$ ls

Running git submodule update --init in the misoc directory and then python setup.py install again fixed the problem.

python setup.py install should probably complain if it can't find the needed files from submodules.

If removing the C version, clean up the python version (e.g. no threads).

(I'm logging this bug for advice on the correct way to implement this and so other people can see the request.)

The Digilent Atlys board is a Spartan 6 prototyping board with a Marvell Alaska Tri-mode PHY (the 88E1111) paired with a Halo HFJ11-1G01E RJ-45 connector.

From the Atlys reference manual, it says

Both MII and GMII interface modes are supported at 10/100/1000 Mb/s.

Sadly it also says;

The data sheet for the Marvell PHY is available from Marvell only with a valid NDA. Please contact
Marvell for more PHY-specific information.

The fact that it supports the MII and GMII interface and you seem to have support at https://github.com/enjoy-digital/liteeth/blob/master/liteeth/phy/gmii.py - would it just be a matter of connecting it up? As well;

EDK-based designs can access the PHY using either the xps_ethernetlite IP core for 10/100 Mbps
designs, or the xps_ll_temac IP core for 10/100/1000 Mbps designs.

More useful information seems to be;

Default settings used at power-on or reset are:

• MII/GMII mode to copper interface
• Auto Negotiation Enabled, advertising all speeds, preferring Slave
• MDIO interface selected, PHY MDIO address = 00111
• No asymmetric pause, no MAC pause, automatic crossover enabled
• Energy detect on cable disabled (Sleep Mode disabled), interrupt polarity LOW

Here is a wiring diagram;

BTW We had a student work on using the ethernet interface directly last year. The result of his work can be found at https://docs.google.com/document/d/1PSjfm6eS0B3UUPJmPf7PH0tNsF7ZFKIKfPldmF3ucKY/edit and http://hdmi2ethernet.blogspot.com.au/

(Copied from original enjoy-digital/liteeth#2 at @enjoy-digital 's request.)

Paths generated in top.prj and top.xst are incorrect when ISE is used under Windows.

I think most Windows users would want to use ISE already installed under Windows rather than having a second installation under Cygwin.

A good option in my opinion would be to allow the user to provide a "windows-style" path to the cygwin directory. Generated gateware can then easily compiled from the ISE command prompt under Windows.

Examples of generated paths:

verilog work /usr/lib/python3.6/site-packages/misoc-0.6.dev0-py3.6.egg/misoc/cores/lm32/verilog/submodule/rtl/lm32_dcache.v

Example of desired path:

verilog work D:\cygwin64\lib\python3.6\site-packages\misoc-0.6.dev0-py3.6.egg\misoc\cores\lm32\verilog\submodule\rtl\lm32_dcache.v

Would be good to have a test bench for this component as well.

As the MII/GMII clock detection is intermittently not working on my board (selecting the wrong mode) I had a look at the code and found several problems:

• contrary to what the comment says the counter reset does need a clock domain transfer. This has nothing to do with the speed of the reset, but making sure that the reset is deasserted at all flops at the same time.
• clock domain transfer of a bus is a complex problem and is not a matter of simply inserting MultiReg on it, as not all bits travel at the same time through the double-latch. Since this is a simply a counter here, using Gray code is one solution (like it's done in the async FIFOs, and the RTIO core for reading the timestamp counter value in the CPU domain). Without Gray coding, large errors can appear every time there is a carry on a high-order bit in the counter.
• timing stuff based on the time spent in printf is a gross and fragile hack. I would put the whole clock detection and MII/GMII switching mechanism in gateware anyway.

Should work but doesn't.

If you create a CONTRIBUTING (or CONTRIBUTING.md) file in your repository in your repo with some quick instructions on how to contribute then github will include this when you open pull requests or try and log issues. See https://github.com/blog/1184-contributing-guidelines

Two things which would be nice to have are;

• What type of issues should be logged and what details they should include.
• How / where to send patches if not using mailing lists. The instructions in the README are probably a good start;

• send us the modifications and improvements you have done to MiSoC.
  The use of "git format-patch" is recommended. If your submission is large
  and complex and/or you are not sure how to proceed, feel free to discuss it
  on the mailing list or IRC (#m-labs on Freenode) beforehand.

In misoc/targets/papilio_pro.py:

self.register_rom(self.spiflash.bus)

defaults to a rom size of 0xa000. This is too small for the current bios image and results in an overflow when software is compiled:

lm32-elf-ld: bios.elf section `.rodata' will not fit in region `rom'
lm32-elf-ld: region `rom' overflowed by 1156 bytes

The size can be adjusted by replacing above line with the following:

self.register_rom(self.spiflash.bus,rom_size=0xb000)

Are there any other steps needed after rom size has been adjusted?
How does the rom size interact with cpu_reset_address?
What does the variable "dummy" do in the SpiFlash class? Default is 15, papilio pro sets dummy to 4.

The converter should go into the correct state by itself due to eop.

The problem is caused by using set() objects and then looping over them.

One example is the following;

    for cd_name in list_clock_domains(f):
        try:
            f.clock_domains[cd_name]
        except KeyError:
            if create_clock_domains:
                cd = ClockDomain(cd_name)
                f.clock_domains.append(cd)
                ios |= {cd.clk, cd.rst}
            else:
                raise KeyError("Unresolved clock domain: '"+cd_name+"'")

Which will create the clock domain objects in random order.

The use of set() seems to be mostly in-conjunction with the _Fragment.specials in migen/fhdl/structure.py

Here is some examples of the differences;

cd migen/examples/basic
rm -rf 1 2; mkdir 1; mkdir 2; for p in $(grep -l "verilog.convert(" *.py); do for i in 1 2; do export PYTHONHASHSEED=$i; python $p > $i/$p.v; done; done; diff -s -u -r 1 2

Files 1/arrays.py.v and 2/arrays.py.v are identical
Files 1/complex.py.v and 2/complex.py.v are identical
Files 1/fsm.py.v and 2/fsm.py.v are identical
Files 1/hamming.py.v and 2/hamming.py.v are identical
Files 1/local_cd.py.v and 2/local_cd.py.v are identical
diff -s -u -r 1/memory.py.v 2/memory.py.v
--- 1/memory.py.v       2015-09-27 00:59:59.645287496 +1000
+++ 2/memory.py.v       2015-09-27 00:59:59.745288998 +1000
@@ -7,10 +7,10 @@
        input [6:0] p2_adr,
        output [31:0] p2_dat_r,
        input p2_re,
-       input rd_clk,
-       input rd_rst,
        input sys_clk,
-       input sys_rst
+       input sys_rst,
+       input rd_clk,
+       input rd_rst
 );


Files 1/namer.py.v and 2/namer.py.v are identical
diff -s -u -r 1/psync.py.v 2/psync.py.v
--- 1/psync.py.v        2015-09-27 01:00:00.065293793 +1000
+++ 2/psync.py.v        2015-09-27 01:00:00.153295111 +1000
@@ -2,10 +2,10 @@
 module top(
        input i,
        output o,
-       input to_clk,
-       input to_rst,
        input from_clk,
-       input from_rst
+       input from_rst,
+       input to_clk,
+       input to_rst
 );

 reg toggle_i = 1'd0;
Files 1/record.py.v and 2/record.py.v are identical
Files 1/reslice.py.v and 2/reslice.py.v are identical
Files 1/simple_gpio.py.v and 2/simple_gpio.py.v are identical
Files 1/tristate.py.v and 2/tristate.py.v are identical
Files 1/two_dividers.py.v and 2/two_dividers.py.v are identical

Sadly python doesn't have a "drop in OrderedSet()" object. See http://stackoverflow.com/questions/1653970/does-python-have-an-ordered-set for more information

There have been a few discussions of organizing the misoc tree. There seem to be two groups of challenges:

misoc python package namespace

Misoc could probably become a real python package. Then using misoc components from a project does not require reverse calling make.py -X ... from the misoc directory but can be handled at the project's discretion and from within the project. miscolib could also be just misoc for that purpose.

The top executable misoc (or misoc_make, f.k.a make.py) could live inside misoc. and an executable script with the correct python interpreter can be generated by the packaging infrastructure.

__init__.py should either be empty everywhere or consist purely of code that initializes/manages the namespace. The file name should do a reasonable job of describing the file's contents. Directories containing only __init__.py can always be replaced by a single .py file with the name of the directory a level up.

We could get rid of the topic groupings. Reliably grouping into com, mem, video, others, tools, and soc is difficult or impossible. Does PCI do just communication or can it also do memory-like things? Can SATA be used to do communication? Or are both tools because they sound like more or less generic busses? What is in others as compared to tools? Why is timer in cpu? Do all components that do not fit any other category but use CSRs go into cpu? Why is the memtest tool deep in misoclib.mem.sdram.frontend but LiteScopeLA in misoclib.tools.litescope.frontend.la?

Also, within a component, if there are frontends, why are there never any backends but many phys? Do the components really need directories within them? Would litescope not be very readable with just port.py, storage.py, trigger.py, io.py (or gpio.py), logic_analyzer.py, and an __init__.py that pulls them together?

Instead of

from misoclib.tools.litescope.common import *
from misoclib.tools.litescope.core.port import LiteScopeTerm
from misoclib.tools.litescope.frontend.io import LiteScopeIO
from misoclib.tools.litescope.frontend.la import LiteScopeLA

we could have from misoc import litescope and then self.submodules += litescope.LogicAnalyzer(...).

Top-level examples and targets that use several misoc components to build actual bitstreams should probably not be living deep in the misoc namespace (misoclib.tools.litescope.example_designs.targets.simple) but either at misoc.targets.litescope (maybe add _simple, no deeper hierarchy) if they can be reused or in /examples outside the misoc package namespace. And they could do something useful if executed (i.e. run/build themselves).

Having non-gateware python code like host tools, data format codecs etc in the various components does not seem to be too confusing and rhymes well with the metaprogramming style of migen. Could the contents of misoclib.tools.litescope.software.driver.la not be in the same file (or at least in the same directory) as misoclib.tools.litescope.frontend.la?

It seems to be a standard pattern to locate unittests (probably not testbenches where you have to look at a vcd afterwards) within test/ next to the module they test. nose and others can find them.

Making it a real python package suggests moving non-python contents out of misoclib/ somewhere else.

Non-python components

Documentation that currently lives deep inside misoclib could be moved to /doc.

/tools/* could be moved into misoc if they are python scripts and executables with the correct interpreter can be generated automatically using the packaging infrastructure.

/extcores/* items could be located and handled using the packaging infrastructure (https://pythonhosted.org/setuptools/setuptools.html#including-data-files).

/software/* items could support building out-of-tree. That solves the pitfalls of having to rebuild bios, library, and headers and potentially flashing the wrong one when switching between projects using misoc. E.g. https://github.com/libopencm3/libopencm3 seems to do that nicely for very variable configurations.

Without running;

git submodule init
git submodule update

You get the following error;

make: Entering directory `/usr/local/google/home/tansell/foss/m-labs/misoc/software/bios'
 CC       isr.o
 CC       sdram.o
 CC       main.o
 CC       boot-helper-lm32.o
 CC       boot.o
 CC       dataflow.o
make -C ../../software/libcompiler-rt
make[1]: Entering directory `/usr/local/google/home/tansell/foss/m-labs/misoc/software/libcompiler-rt'
make[1]: *** No rule to make target `divsi3.o', needed by `libcompiler-rt.a'.  Stop.
make[1]: Leaving directory `/usr/local/google/home/tansell/foss/m-labs/misoc/software/libcompiler-rt'
make: *** [libs] Error 2
make: Leaving directory `/usr/local/google/home/tansell/foss/m-labs/misoc/software/bios'
Traceback (most recent call last):
  File "./make.py", line 180, in <module>
    raise OSError("BIOS build failed")
OSError: BIOS build failed

The make.py or Makefile could check if submodules are initialized or not.

The default Wishbone address size of 30 results in unnecessarily large DMA address registers, especially when SDRAM data is > 32-bit on a 32-bit CPU.

e136030#commitcomment-17331821

I'm just trying to follow the "[> Quick start guide" guide from the README.md at https://github.com/m-labs/misoc

First step is listed as;

1. Install Python 3.3+, Migen and FPGA vendor's development tools.
   Get Migen from: https://github.com/m-labs/migen

I clicked the link to migen and it is very unclear on how I should be installing migen. There is no "migen install instructions" at https://github.com/m-labs/migen

This leads me to a couple of questions;

• Could the Migen link to a better "migen install page"?
• Does such a "Migen install page" exist?
• Is "Migen" just a python module? Could it be installed in a virtualenv or via pip?

It looks like there is lot of useful instructions at http://m-labs.hk/artiq/manual/installing.html and http://m-labs.hk/gateware.html - specially the http://m-labs.hk/migen-tutorial.pdf document.

This will probably happen as part of #17 (as if misoc is installed into the root of the system, it won't be able to write to the directory it is installed into) but thought I would specifically call it out in a separate issue.

At the moment it is my understanding that misoc creates the following things;

• generated header files - This currently end up in misoc/software/include/generated/
• compiler objects - This currently end up in C library directories misoc/software/xxxx
• xilinx output - This currently ends up in misoc/build

Did I miss anything?

@enjoy-digital why was that code duplicated?

CSRBankArray should take a map of the peripherals it should connect to, and ignore the others. That map should be equal to the current csr_map in SoC classes.

The current mechanism uses introspection and attempts to map everything that has get_csrs & friends methods, which makes it messy to have multiple CSR banks in a SoC.

Right now:

[FLTERM] Starting....
Traceback (most recent call last):
  File "miniconda/bin/flterm", line 9, in <module>
    load_entry_point('misoc==0.1', 'console_scripts', 'flterm')()
  File "/home/whitequark/miniconda/lib/python3.5/site-packages/misoc/tools/flterm.py", line 278, in main
    flterm.join(True)
  File "/home/whitequark/miniconda/lib/python3.5/site-packages/misoc/tools/flterm.py", line 256, in join
    self.writer_thread.join()
  File "/home/whitequark/miniconda/lib/python3.5/threading.py", line 1054, in join
    self._wait_for_tstate_lock()
  File "/home/whitequark/miniconda/lib/python3.5/threading.py", line 1070, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt

I have already fixed this once.

On windows, we need to run the console as administrator to use symlinks which is very un-convenient.
Can I change this: https://github.com/m-labs/misoc/blob/master/misoc/integration/builder.py#L110
with this:

if sys.platform == "win32":
    # using symlinks on Windows is not convenient (console
    # needs to be run as administrator), copy Makefile instead.
    shutil.copy(src, dst)
else:
    os.symlink(src, dst)

binutils and gcc have been cross-compiled and installed, python is 3.5.2

It seems some python files included are python2 syntax?

~/misoc$ sudo python3 setup.py install
/usr/lib/python3/dist-packages/setuptools/dist.py:285: UserWarning: Normalizing '0.6.dev' to '0.6.dev0'
normalized_version,
running install
Checking .pth file support in /usr/local/lib/python3.5/dist-packages/
/usr/bin/python3 -E -c pass
TEST PASSED: /usr/local/lib/python3.5/dist-packages/ appears to support .pth files
running bdist_egg
running egg_info
writing dependency_links to misoc.egg-info/dependency_links.txt
writing misoc.egg-info/PKG-INFO
writing requirements to misoc.egg-info/requires.txt
writing top-level names to misoc.egg-info/top_level.txt
writing entry points to misoc.egg-info/entry_points.txt
reading manifest file 'misoc.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'misoc.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
byte-compiling build/bdist.linux-x86_64/egg/misoc/software/compiler_rt/lib/asan/scripts/asan_symbolize.py to asan_symbolize.cpython-35.pyc
File "build/bdist.linux-x86_64/egg/misoc/software/compiler_rt/lib/asan/scripts/asan_symbolize.py", line 87
print ' '.join(cmd)
^
SyntaxError: invalid syntax

byte-compiling build/bdist.linux-x86_64/egg/misoc/software/compiler_rt/lib/dfsan/scripts/build-libc-list.py to build-libc-list.cpython-35.pyc
File "build/bdist.linux-x86_64/egg/misoc/software/compiler_rt/lib/dfsan/scripts/build-libc-list.py", line 96
print 'fun:%s=uninstrumented' % f
^
SyntaxError: Missing parentheses in call to 'print'

byte-compiling build/bdist.linux-x86_64/egg/misoc/software/compiler_rt/lib/sanitizer_common/scripts/sancov.py to sancov.cpython-35.pyc
File "build/bdist.linux-x86_64/egg/misoc/software/compiler_rt/lib/sanitizer_common/scripts/sancov.py", line 87
print "0x%x" % i
^
SyntaxError: Missing parentheses in call to 'print'

byte-compiling build/bdist.linux-x86_64/egg/misoc/software/compiler_rt/test/asan/android_commands/android_common.py to android_common.cpython-35.pyc
File "build/bdist.linux-x86_64/egg/misoc/software/compiler_rt/test/asan/android_commands/android_common.py", line 13
print args
^
SyntaxError: Missing parentheses in call to 'print'

byte-compiling build/bdist.linux-x86_64/egg/misoc/software/compiler_rt/test/asan/android_commands/android_compile.py to android_compile.cpython-35.pyc
File "build/bdist.linux-x86_64/egg/misoc/software/compiler_rt/test/asan/android_commands/android_compile.py", line 24
print "No output file name!"
^
SyntaxError: Missing parentheses in call to 'print'

copying misoc.egg-info/PKG-INFO -> build/bdist.linux-x86_64/egg/EGG-INFO
copying misoc.egg-info/SOURCES.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying misoc.egg-info/dependency_links.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying misoc.egg-info/entry_points.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying misoc.egg-info/requires.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying misoc.egg-info/top_level.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
writing build/bdist.linux-x86_64/egg/EGG-INFO/native_libs.txt
zip_safe flag not set; analyzing archive contents...
python3.5.pycache.site.cpython-35: module references file
python3.5.pycache.warnings.cpython-35: module references file
python3.5.encodings.pycache.init.cpython-35: module references file
python3.5.importlib.pycache.init.cpython-35: module references file
python3.5.importlib.pycache.init.cpython-35: module references path
python3.5.importlib.pycache._bootstrap.cpython-35: module references file
python3.5.importlib.pycache._bootstrap.cpython-35: module references path
python3.5.importlib.pycache._bootstrap_external.cpython-35: module references file
python3.5.importlib.pycache._bootstrap_external.cpython-35: module references path
python3.5.importlib.pycache.util.cpython-35: module references path
python3.5.site-packages.pip.pycache.init.cpython-35: module references file
python3.5.site-packages.pip.pycache.locations.cpython-35: module references file
python3.5.site-packages.pip.pycache.main.cpython-35: module references file
python3.5.site-packages.pip._vendor.pkg_resources.pycache.init.cpython-35: module references file
python3.5.site-packages.pip._vendor.pkg_resources.pycache.init.cpython-35: module references path
python3.5.site-packages.pip._vendor.distlib.pycache.resources.cpython-35: module references file
python3.5.site-packages.pip._vendor.distlib.pycache.resources.cpython-35: module references path
python3.5.site-packages.pip._vendor.pycache.six.cpython-35: module references path
python3.5.site-packages.pip._vendor.pycache.init.cpython-35: module references file
python3.5.site-packages.pip._vendor.pycache.re-vendor.cpython-35: module references file
python3.5.site-packages.pip._vendor.requests.packages.urllib3.packages.pycache.six.cpython-35: module references path
python3.5.site-packages.pip._vendor.requests.pycache.certs.cpython-35: module references file
Traceback (most recent call last):
File "setup.py", line 39, in
"mkmscimg=misoc.tools.mkmscimg:main",
File "/usr/lib/python3.5/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/lib/python3.5/distutils/dist.py", line 955, in run_commands
self.run_command(cmd)
File "/usr/lib/python3.5/distutils/dist.py", line 974, in run_command
cmd_obj.run()
File "/usr/lib/python3/dist-packages/setuptools/command/install.py", line 67, in run
self.do_egg_install()
File "/usr/lib/python3/dist-packages/setuptools/command/install.py", line 109, in do_egg_install
self.run_command('bdist_egg')
File "/usr/lib/python3.5/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "/usr/lib/python3.5/distutils/dist.py", line 974, in run_command
cmd_obj.run()
File "/usr/lib/python3/dist-packages/setuptools/command/bdist_egg.py", line 209, in run
os.path.join(archive_root, 'EGG-INFO'), self.zip_safe()
File "/usr/lib/python3/dist-packages/setuptools/command/bdist_egg.py", line 245, in zip_safe
return analyze_egg(self.bdist_dir, self.stubs)
File "/usr/lib/python3/dist-packages/setuptools/command/bdist_egg.py", line 355, in analyze_egg
safe = scan_module(egg_dir, base, name, stubs) and safe
File "/usr/lib/python3/dist-packages/setuptools/command/bdist_egg.py", line 392, in scan_module
code = marshal.load(f)
ValueError: bad marshal data (unknown type code)

New misoc builder automatically builds libdyld and libunwind libs.

Since simple targets don't need it and libdyld supports only or1k, we should build those only when needed.

https://github.com/m-labs/misoc/blob/master/misoc/interconnect/wishbone.py#L12

 "liballoc",
 "libm",
 "libdyld",
 "libunwind"

are not needed for simple SoCs and libdyld is only implemented for or1k. (ie we are not longer able to build lm32 SoCs).

Can we only keep this for misoc_software_packages:

misoc_software_packages = [
    "libcompiler_rt",
    "libbase",
    "libnet",
    "bios"
]

and add the others packages with add_software_package in ARTIQ's targets?

(I'm logging this bug for advice on the correct way to implement this and so other people can see the request.)

It looks like you already support the GMII interface at https://github.com/enjoy-digital/liteeth/blob/master/liteeth/phy/gmii.py but we need to support RGMII ICs.

The RGMII interface reduces the number of pins needed from 24 pins for GMII to 12 pins. This reduction is achieved by clocking data on both the rising and falling edges of the clock.

From wikipedia;

RGMII uses half the number of data pins as used in the GMII interface. This reduction is achieved by clocking data on both the rising and falling edges of the clock in 1000 Mbit/s operation, and by eliminating non-essential signals (carrier-sense and collision-indication). Thus RGMII consists only of: RX_CTL, RXC, RXD[3:0], TX_CTL, TXC, TXD[3:0](12 pins, as opposed to GMII's 24).

Unlike GMII, the transmit clock signal is always provided by the MAC on the TXC line, rather than being provided by the PHY for 10/100 Mbit/s operation and by the MAC at 1000 Mbit/s. Source-synchronous clocking is used: the clock signal that is output (by either the PHY or the MAC) is synchronous with the data signals. This requires the PCB to be designed to add a 1.5-2ns delay to the clock signal in order to make the setup and hold times on the sink. RGMII v2.0 specifies an optional internal delay, obviating the need for the PCB designer to add delay; this is known as RGMII-ID.

What is the best way to go about adding this?

(Copied from original enjoy-digital/liteeth#1 at @enjoy-digital 's request.)

Needed for Kasli as RTIO master

• https://github.com/alexforencich/verilog-ethernet/tree/master/rtl
• https://github.com/freecores/1000base-x

New misoc builder is using symbolic links to build cpu's software.

On windows machines, only administrators can create symbolic links so builder must be run as administrator.

That would be fine to avoid that if possible, if not we should maybe indicate it somewhere.

If this is allowed then the Upconverter needs fixing.

enjoy-digital/litex@c02de16#diff-4f79352cf10ff37ab2faaa15ca9f6281L48

https://ssl.serverraum.org/lists-archive/devel/2016-January/004173.html
Required to fix the analyzer "data stuck" problem on ARTIQ, unless we drop dataflow completely.

It would be nice to have a "spi settings" thing for different SPI flash chips following the same vian at https://github.com/m-labs/misoc/blob/master/misoc/cores/sdram_settings.py#L60 for the SDRAM ICs.