+++ /dev/null
-migen API Documentation
-=======================
-
-:mod:`fhdl.structure` Module
-----------------------------
-
-.. automodule:: migen.fhdl.structure
- :members:
- :show-inheritance:
-
-:mod:`fhdl.bitcontainer` Module
--------------------------------
-
-.. automodule:: migen.fhdl.bitcontainer
- :members:
- :show-inheritance:
-
-:mod:`genlib.fifo` Module
--------------------------
-
-.. automodule:: migen.genlib.fifo
- :members:
- :show-inheritance:
-
-:mod:`genlib.coding` Module
----------------------------
-
-.. automodule:: migen.genlib.coding
- :members:
- :show-inheritance:
-
-:mod:`genlib.sort` Module
--------------------------
-
-.. automodule:: migen.genlib.sort
- :members:
- :show-inheritance:
+++ /dev/null
-Bus support
-###########
-
-Migen Bus contains classes providing a common structure for master and slave interfaces of the following buses:
-
-* Wishbone [wishbone]_, the general purpose bus recommended by Opencores.
-* CSR-2 (see :ref:`csr2`), a low-bandwidth, resource-sensitive bus designed for accessing the configuration and status registers of cores from software.
-* LASMIbus (see :ref:`lasmi`), a bus optimized for use with a high-performance frequency-ratio SDRAM controller.
-* DFI [dfi]_ (partial), a standard interface protocol between memory controller logic and PHY interfaces.
-
-.. [wishbone] http://cdn.opencores.org/downloads/wbspec_b4.pdf
-.. [dfi] http://www.ddr-phy.org/
-
-It also provides interconnect components for these buses, such as arbiters and address decoders. The strength of the Migen procedurally generated logic can be illustrated by the following example: ::
-
- self.submodules.wbcon = wishbone.InterconnectShared(
- [cpu.ibus, cpu.dbus, ethernet.dma, audio.dma],
- [(lambda a: a[27:] == 0, norflash.bus),
- (lambda a: a[27:] == 1, wishbone2lasmi.wishbone),
- (lambda a: a[27:] == 3, wishbone2csr.wishbone)])
-
-In this example, the interconnect component generates a 4-way round-robin arbiter, multiplexes the master bus signals into a shared bus, and connects all slave interfaces to the shared bus, inserting the address decoder logic in the bus cycle qualification signals and multiplexing the data return path. It can recognize the signals in each core's bus interface thanks to the common structure mandated by Migen Bus. All this happens automatically, using only that much user code.
-
-
-Configuration and Status Registers
-**********************************
-
-.. _csr2:
-
-CSR-2 bus
-=========
-The CSR-2 bus is a low-bandwidth, resource-sensitive bus designed for accessing the configuration and status registers of cores from software.
-
-It is the successor of the CSR bus used in Milkymist SoC 1.x, with two modifications:
-
-* Up to 32 slave devices (instead of 16)
-* Data words are 8 bits (instead of 32)
-
-.. _bank:
-
-Generating register banks
-=========================
-Migen Bank is a system comparable to wishbone-gen [wbgen]_, which automates the creation of configuration and status register banks and interrupt/event managers implemented in cores.
-
-.. [wbgen] http://www.ohwr.org/projects/wishbone-gen
-
-Bank takes a description made up of a list of registers and generates logic implementing it with a slave interface compatible with Migen Bus.
-
-The lowest-level description of a register is provided by the ``CSR`` class, which maps to the value at a single address on the target bus. The width of the register needs to be less than or equal to the bus word width. All accesses are atomic. It has the following signal properties to interface to the user design:
-
-* ``r``, which contains the data written from the bus interface.
-* ``re``, which is the strobe signal for ``r``. It is active for one cycle, after or during a write from the bus. ``r`` is only valid when ``re`` is high.
-* ``w``, which must provide at all times the value to be read from the bus.
-
-Names of CSRs can be omitted if they can be extracted from the variable name. When using this automatic naming feature, prefixes ``_``, ``r_`` and ``_r_`` are removed.
-
-Compound CSRs (which are transformed into ``CSR`` plus additional logic for implementation) provide additional features optimized for common applications.
-
-The ``CSRStatus`` class is meant to be used as a status register that is read-only from the CPU. The user design is expected to drive its ``status`` signal. The advantage of using ``CSRStatus`` instead of using ``CSR`` and driving ``w`` is that the width of ``CSRStatus`` can be arbitrary. Status registers larger than the bus word width are automatically broken down into several ``CSR`` registers to span several addresses. Be careful, though: the atomicity of reads is not guaranteed.
-
-The ``CSRStorage`` class provides a memory location that can be read and written by the CPU, and read and optionally written by the design. It can also span several CSR addresses. An optional mechanism for atomic CPU writes is provided; when enabled, writes to the first CSR addresses go to a back-buffer whose contents are atomically copied to the main buffer when the last address is written. When ``CSRStorage`` can be written to by the design, the atomicity of reads by the CPU is not guaranteed.
-
-A module can provide bus-independent CSRs by implementing a ``get_csrs`` method that returns a list of instances of the classes described above. Similary, bus-independent memories can be returned as a list by a ``get_memories`` method.
-
-To avoid listing those manually, a module can inherit from the ``AutoCSR`` class, which provides ``get_csrs`` and ``get_memories`` methods that scan for CSR and memory attributes and return their list. If the module has child objects that implement ``get_csrs`` or ``get_memories``, they will be called by the ``AutoCSR`` methods and their CSR and memories added to the lists returned, with the child objects' names as prefixes.
-
-Generating interrupt controllers
-================================
-The event manager provides a systematic way to generate standard interrupt controllers.
-
-Its constructor takes as parameters one or several *event sources*. An event source is an instance of either:
-
-* ``EventSourcePulse``, which contains a signal ``trigger`` that generates an event when high. The event stays asserted after the ``trigger`` signal goes low, and until software acknowledges it. An example use is to pulse ``trigger`` high for 1 cycle after the reception of a character in a UART.
-* ``EventSourceProcess``, which contains a signal ``trigger`` that generates an event on its falling edge. The purpose of this event source is to monitor the status of processes and generate an interrupt on their completion. The signal ``trigger`` can be connected to the ``busy`` signal of a dataflow actor, for example.
-* ``EventSourceLevel``, whose ``trigger`` contains the instantaneous state of the event. It must be set and released by the user design. For example, a DMA controller with several slots can use this event source to signal that one or more slots require CPU attention.
-
-The ``EventManager`` provides a signal ``irq`` which is driven high whenever there is a pending and unmasked event. It is typically connected to an interrupt line of a CPU.
-
-The ``EventManager`` provides a method ``get_csrs``, that returns a bus-independent list of CSRs to be used with Migen Bank as explained above. Each event source is assigned one bit in each of those registers. They are:
-
-* ``status``: contains the current level of the trigger line of ``EventSourceProcess`` and ``EventSourceLevel`` sources. It is 0 for ``EventSourcePulse``. This register is read-only.
-* ``pending``: contains the currently asserted events. Writing 1 to the bit assigned to an event clears it.
-* ``enable``: defines which asserted events will cause the ``irq`` line to be asserted. This register is read-write.
-
-.. _lasmi:
-
-Lightweight Advanced System Memory Infrastructure
-*************************************************
-
-Rationale
-=========
-The lagging of the DRAM semiconductor processes behind the logic processes has led the industry into a subtle way of ever increasing memory performance.
-
-Modern devices feature a DRAM core running at a fraction of the logic frequency, whose wide data bus is serialized and deserialized to and from the faster clock domain. Further, the presence of more banks increases page hit rate and provides opportunities for parallel execution of commands to different banks.
-
-A first-generation SDR-133 SDRAM chip runs both DRAM, I/O and logic at 133MHz and features 4 banks. A 16-bit chip has a 16-bit DRAM core.
-
-A newer DDR3-1066 chip still runs the DRAM core at 133MHz, but the logic at 533MHz (4 times the DRAM frequency) and the I/O at 1066Mt/s (8 times the DRAM frequency). A 16-bit chip has a 128-bit internal DRAM core. Such a device features 8 banks. Note that the serialization also introduces multiplied delays (e.g. CAS latency) when measured in number of cycles of the logic clock.
-
-To take full advantage of these new architectures, the memory controller should be able to peek ahead at the incoming requests and service several of them in parallel, while respecting the various timing specifications of each DRAM bank and avoiding conflicts for the shared data lines. Going further in this direction, a controller able to complete transfers out of order can provide even more performance by:
-
-#. grouping requests by DRAM row, in order to minimize time spent on precharging and activating banks.
-#. grouping requests by direction (read or write) in order to minimize delays introduced by bus turnaround and write recovery times.
-#. being able to complete a request that hits a page earlier than a concurrent one which requires the cycling of another bank.
-
-The first two techniques are explained with more details in [drreorder]_.
-
-.. [drreorder] http://www.xilinx.com/txpatches/pub/documentation/misc/improving%20ddr%20sdram%20efficiency.pdf
-
-Migen and MiSoC implement their own bus, called LASMIbus, that features the last two techniques. Grouping by row had been previously explored with ASMI, but difficulties in achieving timing closure at reasonable latencies in FPGA combined with uncertain performance pay-off for some applications discouraged work in that direction.
-
-Topology and transactions
-=========================
-The LASMI consists of one or several memory controllers (e.g. LASMIcon from MiSoC), multiple masters, and crossbar interconnect.
-
-Each memory controller can expose several bank machines to the crossbar. This way, requests to different SDRAM banks can be processed in parallel.
-
-Transactions on LASMI work as follows:
-
-1. The master presents a valid address and write enable signals, and asserts its strobe signal.
-2. The crossbar decodes the bank address and, in a multi-controller configuration, the controller address and connects the master to the appropriate bank machine.
-3. The bank machine acknowledges the request from the master. The master can immediately issue a new request to the same bank machine, without waiting for data.
-4. The bank machine sends data acknowledgements to the master, in the same order as it issued requests. After receiving a data acknowldegement, the master must either:
-
- * present valid data after a fixed number of cycles (for writes). Masters must hold their data lines at 0 at all other times so that they can be simply ORed for each controller to produce the final SDRAM write data.
- * sample the data bus after a fixed number of cycles (for reads).
-
-5. In a multi-controller configuration, the crossbar multiplexes write and data signals to route data to and from the appropriate controller.
-
-When there are queued requests (i.e. more request acknowledgements than data acknowledgements), the bank machine asserts its ``lock`` signal which freezes the crossbar connection between the master and the bank machine. This simplifies two problems:
-
-#. Determining to which master a data acknowledgement from a bank machine should be sent.
-#. Having to deal with a master queuing requests into multiple different bank machines which may collectively complete them in a different order than the master issued them.
-
-For each master, transactions are completed in-order by the memory system. Reordering may only occur between masters, e.g. a master issuing a request that hits a page may have it completed sooner than a master requesting earlier a precharge/activate cycle of another bank.
-
-It is suggested that memory controllers use an interface to a PHY compatible with DFI [dfi]_. The DFI clock can be the same as the LASMIbus clock, with optional serialization and deserialization taking place across the PHY, as specified in the DFI standard.
-
-SDRAM burst length and clock ratios
-===================================
-A system using LASMI must set the SDRAM burst length B, the LASMIbus word width W and the ratio between the LASMIbus clock frequency Fa and the SDRAM I/O frequency Fi so that all data transfers last for exactly one LASMIbus cycle.
-
-More explicitly, these relations must be verified:
-
-B = Fi/Fa
-
-W = B*[number of SDRAM I/O pins]
-
-For DDR memories, the I/O frequency is twice the logic frequency.
+++ /dev/null
-Case studies
-############
-
-A VGA framebuffer core
-**********************
-
-Purpose
-=======
-
-The purpose of the VGA framebuffer core is to scan a buffer in system memory and generate an appropriately timed video signal in order to display the picture from said buffer on a regular VGA monitor.
-
-The core is meant to be integrated in a SoC and is controllable by a CPU which can set parameters such as the framebuffer address, video resolution and timing parameters.
-
-This case study highlights what tools Migen provides to design such a core.
-
-Architecture
-============
-
-The framebuffer core is designed using the Migen dataflow system (see :ref:`dataflow`). Its block diagram is given in the figure below:
-
-.. figure:: fbflow.png
- :scale: 50 %
-
- Data flow graph of the framebuffer core.
-
-Actors drawn with a blue background are designed specifically for the framebuffer cores, the others are generic actors from the Migen library. Migen also provides the interconnect logic between the actors.
-
-Frame initiator
-===============
-
-The frame initiator generates tokens that correspond each to one complete scan of the picture (active video, synchronization pulses, front and back porches). The token contains the address and the length of the framebuffer used for the active video region, and timing parameters to generate the synchronization and porches.
-
-Switching the framebuffer address (without tearing) is simply done by generating a token with the new address. Tearing will not occur since the new token will accepted only after the one from the previous frame has been processed (i.e. all addresses within the previous frame have been generated).
-
-Video resolution can be changed in a similar way.
-
-To interface with the CPU, the frame initiator uses Migen to provide a CSR bank (see :ref:`bank`).
-
-Pixel fetcher
-=============
-
-The pixel fetcher is made up of the address generator, the LASMI reader and the unpacker.
-
-The address generator is a simple counter that takes one token containing the pair ``(base, length)`` and generates ``length`` tokens containing ``base``, ..., ``base+length-1``. It is implemented using a Migen library component (see :ref:`intsequence`).
-
-Those addresses are fed into the LASMI reader (see :ref:`busactors`) that fetches the corresponding locations from the system memory. The LASMI reader design supports several outstanding requests, which enables it to sustain a high throughput in spite of memory latency. This feature makes it possible to utilize the available memory bandwidth to the full extent, and reduces the need for on-chip buffering.
-
-LASMI memory words are wide and contain several pixels. The unpacking actor (see :ref:`structuring`) takes a token containing a memory word and "chops" it into multiple tokens containing one pixel each.
-
-Video timing generator
-======================
-
-The video timing generator is the central piece of the framebuffer core. It takes one token containing the timing parameters of a frame, followed by as many tokens as there are pixels in the frame. It generates tokens containing the status of the horizontal/vertical synchronization signals and red/green/blue values. When the contents of those tokens are sent out at the pixel clock rate (and the red/green/blue value converted to analog), they form a valid video signal for one frame.
-
-DAC driver
-==========
-
-The DAC driver accepts and buffers the output tokens from the video timing generator, and sends their content to the DAC and video port at the pixel clock rate using an asynchronous FIFO.
# All configuration values have a default; values that are commented out
# serve to show the default.
-import sys, os
-
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
# General information about the project.
project = u'Migen'
-copyright = u'2012, Sebastien Bourdeauducq'
+copyright = u'2011-2015, M-Labs Limited'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
-version = 'X'
+version = '1.0'
# The full version, including alpha/beta/rc tags.
-release = 'X'
+release = '1.0'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
-html_theme = 'default'
+html_theme = 'alabaster'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
+++ /dev/null
-.. _dataflow:
-
-Dataflow
-########
-
-Many hardware acceleration problems can be expressed in the dataflow paradigm. It models a program as a directed graph of the data flowing between functions. The nodes of the graph are functional units called actors, and the edges represent the connections (transporting data) between them.
-
-Actors communicate by exchanging data units called tokens. A token contains arbitrary (user-defined) data, which is a record containing one or many fields, a field being a bit vector or another record. Token exchanges are atomic (i.e. all fields are transferred at once from the transmitting actor to the receiving actor).
-
-Actors
-******
-
-Actors and endpoints
-====================
-
-Actors in Migen are implemented in FHDL. This low-level approach maximizes the practical flexibility: for example, an actor can manipulate the bus signals to implement a DMA master in order to read data from system memory (see :ref:`busactors`).
-
-Token exchange ports of actors are called endpoints. Endpoints are unidirectional and can be sources (which transmit tokens out of the actor) or sinks (which receive tokens into the actor).
-
-.. figure:: actors_endpoints.png
- :scale: 50 %
-
- Actors and endpoints.
-
-The flow of tokens is controlled using two handshake signals (strobe and acknowledgement) which are implemented by every endpoint. The strobe signal is driven by sources, and the acknowledgement signal by sinks.
-
-======= ======= ====================================================================================================
-``stb`` ``ack`` Situation
-======= ======= ====================================================================================================
-0 0 The source endpoint does not have data to send, and the sink endpoint is not ready to
- accept data.
-0 1 The sink endpoint is ready to accept data, but the source endpoint has currently no data
- to send. The sink endpoint is not required to keep its ``ack`` signal asserted.
-1 0 The source endpoint is trying to send data to the sink endpoint, which is currently not
- ready to accept it. The transaction is *stalled*. The source endpoint must keep ``stb``
- asserted and continue to present valid data until the transaction is completed.
-1 1 The source endpoint is sending data to the sink endpoint which is ready to accept it. The
- transaction is *completed*. The sink endpoint must register the incoming data, as the
- source endpoint is not required to hold it valid at the next cycle.
-======= ======= ====================================================================================================
-
-It is permitted to generate an ``ack`` signal combinatorially from one or several ``stb`` signals. However, there should not be any combinatorial path from an ``ack`` to a ``stb`` signal.
-
-Actors are FHDL modules that have one or several endpoint attributes of the ``migen.flow.actor.Sink`` or ``migen.flow.actor.Source`` type, and a ``busy`` signal.
-
-Endpoint constructors take as parameter the layout of the data record that the endpoint is dealing with.
-
-Record layouts are a list of fields. Each field is described by a pair consisting of:
-
-* The field's name.
-* Either a bit width or a (bit width, signedness) pair if the field is a bit vector, or another record layout if the field is a lower-level record.
-
-For example, this code: ::
-
- class MyActor(Module):
- def __init__(self):
- self.busy = Signal()
- self.operands = Sink([("a", 16), ("b", 16)])
- self.result = Source([("r", 17)])
-
-creates an actor with:
-
-* One sink named ``operands`` accepting data structured as a 16-bit field ``a`` and a 16-bit field ``b``. Note that this is functionally different from having two endpoints ``a`` and ``b``, each accepting a single 16-bit field. With a single endpoint, the data is strobed when *both* ``a`` and ``b`` are valid, and ``a`` and ``b`` are *both* acknowledged *atomically*. With two endpoints, the actor has to deal with accepting ``a`` and ``b`` independently. Plumbing actors (see :ref:`plumbing`) and abstract networks (see :ref:`actornetworks`) provide a systematic way of converting between these two behaviours, so user actors should implement the behaviour that results in the simplest or highest performance design.
-* One source named ``result`` transmitting a single 17-bit field named ``r``.
-
-Accessing the endpoints is done by manipulating the signals inside the ``Source`` and ``Sink`` objects. They hold:
-
-* A signal object ``stb``.
-* A signal object ``ack``.
-* The data payload ``payload``, which is a record with the layout given to the endpoint constructor.
-
-Endpoints can also be used to manipulate packets, this is done by setting packetized parameter to True which adds:
-
-* A signal object ``sop`` (Start Of Packet).
-* A signal object ``eop`` (End Of Packet).
-
-When used in packetized mode, packet parameters (signals that do no change for the duration of a packet) should to be declared in
-param_layout. Declaring these signals in payload_layout will works in most cases but will prevent logic optimizations.
-
-Busy signal
-===========
-
-The basic actor class creates a ``busy`` control signal that actor implementations should drive.
-
-This signal represents whether the actor's state holds information that will cause the completion of the transmission of output tokens. For example:
-
-* A "buffer" actor that simply registers and forwards incoming tokens should drive 1 on ``busy`` when its register contains valid data pending acknowledgement by the receiving actor, and 0 otherwise.
-* An actor sequenced by a finite state machine should drive ``busy`` to 1 whenever the state machine leaves its idle state.
-* An actor made of combinatorial logic is stateless and should tie ``busy`` to 0.
-
-.. _schedmod:
-
-Common scheduling models
-========================
-
-For the simplest and most common scheduling cases, Migen provides logic to generate the handshake signals and the busy signal. This is done through abstract actor classes that examine the endpoints defined by the user and add logic to drive their control signals (i.e. everything except the payload). The ``__init__`` method of the abstract scheduling class must be called after the user has created the endpoints. The ``busy`` signal is created by the abstract scheduling class.
-
-These classes are usable only when the actor has exactly one sink and one source (but those endpoints can contain an arbitrary data structure), and in the cases listed below.
-
-Combinatorial
--------------
-The actor datapath is made entirely of combinatorial logic. The handshake signals pass through. A small integer adder would use this model.
-
-This model is implemented by the ``migen.flow.actor.CombinatorialActor`` class. There are no parameters or additional control signals.
-
-N-sequential
-------------
-The actor consumes one token at its input, and it produces one output token after N cycles. It cannot accept new input tokens until it has produced its output. A multicycle integer divider would use this model.
-
-This model is implemented by the ``migen.flow.actor.SequentialActor`` class. The constructor of this class takes as parameter the number of cycles N. The class provides an extra control signal ``trigger`` that pulses to 1 for one cycle when the actor should register the inputs and start its processing. The actor is then expected to provide an output after the N cycles and hold it constant until the next trigger pulse.
-
-N-pipelined
------------
-This is similar to the sequential model, but the actor can always accept new input tokens. It produces an output token N cycles of latency after accepting an input token. A pipelined multiplier would use this model.
-
-This model is implemented by the ``migen.flow.actor.PipelinedActor`` class. The constructor takes the number of pipeline stages N. There is an extra control signal ``pipe_ce`` that should enable or disable all synchronous statements in the datapath (i.e. it is the common clock enable signal for all the registers forming the pipeline stages).
-
-The Migen actor library
-***********************
-
-.. _plumbing:
-
-Plumbing actors
-===============
-
-Plumbing actors arbitrate the flow of data between actors. For example, when a source feeds two sinks, they ensure that each sink receives exactly one copy of each token transmitted by the source.
-
-Most of the time, you will not need to instantiate plumbing actors directly, as abstract actor networks (see :ref:`actornetworks`) provide a more powerful solution and let Migen insert plumbing actors behind the scenes.
-
-Buffer
-------
-
-The ``Buffer`` registers the incoming token and retransmits it. It is a pipelined actor with one stage. It can be used to relieve some performance problems or ease timing closure when many levels of combinatorial logic are accumulated in the datapath of a system.
-
-When used in a network, abstract instances of ``Buffer`` are automatically configured by Migen (i.e. the appropriate token layout is set).
-
-Combinator
-----------
-
-This actor combines tokens from several sinks into one source.
-
-For example, when the operands of a pipelined multiplier are available independently, the ``Combinator`` can turn them into a structured token that is sent atomically into the multiplier when both operands are available, simplifying the design of the multiplier actor.
-
-Splitter
---------
-
-This actor does the opposite job of the ``Combinator``. It receives a token from its sink, duplicates it into an arbitrary number of copies, and transmits one through each of its sources. It can optionally omit certain fields of the token (i.e. take a subrecord).
-
-For example, an Euclidean division actor generating the quotient and the remainder in one step can transmit both using one token. The ``Splitter`` can then forward the quotient and the remainder independently, as integers, to other actors.
-
-.. _structuring:
-
-Structuring actors
-==================
-
-Cast
-----
-
-This actor concatenates all the bits from the data of its sink (in the order as they appear in the layout) and connects them to the raw bits of its source (obtained in the same way). The source and the sink layouts must contain the same number of raw bits. This actor is a simple "connect-through" which does not use any hardware resources.
-
-It can be used in conjunction with the bus master actors (see :ref:`busactors`) to destructure (resp. structure) data going to (resp. coming from) the bus.
-
-Unpack
-------
-
-This actor takes a token with the fields ``chunk0`` ... ``chunk[N-1]`` (each having the same layout L) and generates N tokens with the layout L containing the data of ``chunk0`` ... ``chunk[N-1]`` respectively.
-
-Pack
-----
-
-This actor receives N tokens with a layout L and generates one token with the fields ``chunk0`` ... ``chunk[N-1]`` (each having the same layout L) containing the data of the N incoming tokens respectively.
-
-Simulation actors
-=================
-
-When hardware implementation is not desired, Migen lets you program actor behaviour in "regular" Python.
-
-For this purpose, it provides a ``migen.actorlib.sim.SimActor`` class. The constructor takes a generator as parameter, which implements the actor's behaviour. The user must derive the ``SimActor`` class and add endpoint attributes. The ``busy`` signal is provided by the ``SimActor`` class.
-
-Generators can yield ``None`` (in which case, the actor does no transfer for one cycle) or one or a tuple of instances of the ``Token`` class. Tokens for sink endpoints are pulled and the "value" field filled in. Tokens for source endpoints are pushed according to their "value" field. The generator is run again after all transactions are completed.
-
-The possibility to push several tokens at once is important to interact with actors that only accept a group of tokens when all of them are available.
-
-The ``Token`` class contains the following items:
-
-* The name of the endpoint from which it is to be received, or to which it is to be transmitted. This value is not modified by the transaction.
-* A dictionary of values corresponding to the fields of the token. Fields that are lower-level records are represented by another dictionary. This item should be set to ``None`` (default) when receiving from a sink.
-
-See ``dataflow.py`` in the examples folder of the Migen sources for a demonstration of the use of these actors.
-
-.. _busactors:
-
-Bus actors
-==========
-
-Migen provides a collection of bus-mastering actors, which makes it possible for dataflow systems to access system memory easily and efficiently.
-
-Wishbone reader
----------------
-
-The ``migen.actorlib.dma_wishbone.Reader`` takes a token representing a 30-bit Wishbone address (expressed in words), reads one 32-bit word on the bus at that address, and transmits the data.
-
-It does so using Wishbone classic cycles (there is no burst or cache support). The actor is pipelined and its throughput is only limited by the Wishbone stall cycles.
-
-Wishbone writer
----------------
-
-The ``migen.actorlib.dma_wishbone.Writer`` takes a token containing a 30-bit Wishbone address (expressed in words) and a 32-bit word of data, and writes that word to the bus.
-
-Only Wishbone classic cycles are supported. The throughput is limited by the Wishbone stall cycles only.
-
-LASMI reader
-------------
-
-The ``migen.actorlib.dma_lasmi.Reader`` requires a LASMI master port at instantiation time. This port defines the address and data widths of the actor and how many outstanding transactions are supported.
-
-Input tokens contain the raw LASMI address, and output tokens are wide LASMI data words.
-
-LASMI writer
-------------
-
-Similarly, Migen provides a LASMI writer actor that accepts tokens containing an address and write data (in the same format as a LASMI word).
-
-Miscellaneous actors
-====================
-
-.. _intsequence:
-
-Integer sequence generator
---------------------------
-
-The integer sequence generator either:
-
-* takes a token containing a maximum value N and generates N tokens containing the numbers 0 to N-1.
-* takes a token containing a number of values N and a offset O and generates N-O tokens containing the numbers O to O+N-1.
-
-The actor instantiation takes several parameters:
-
-* the number of bits needed to represent the maximum number of generated values.
-* the number of bits needed to represent the maximum offset. When this value is 0 (default), then offsets are not supported and the sequence generator accepts tokens which contain the maximum value alone.
-
-The integer sequence generator can be used in combination with bus actors to generate addresses and read contiguous blocks of system memory (see :ref:`busactors`).
-
-.. _actornetworks:
-
-Actor networks
-**************
-
-Graph definition
-================
-
-Migen represents an actor network using the ``migen.flow.network.DataFlowGraph`` class (a directed graph with self-loops and parallel edges).
-
-Nodes of the graph are either:
-
-* An existing actor (*physical actor*).
-* An instance of ``migen.flow.network.AbstractActor``, containing the actor class and a dictionary (*abstract actor*). It means that the actor class should be instantiated with the parameters from the dictionary. This form is needed to enable optimizations such as actor duplication or sharing during elaboration.
-
-Edges of the graph represent the flow of data between actors. They have the following data properties:
-
-* ``source``: a string containing the name of the source endpoint, which can be ``None`` (Python's ``None``, not the string ``"None"``) if the transmitting actor has only one source endpoint.
-* ``sink``: a string containing the name of the sink endpoint, which can be ``None`` if the transmitting actor has only one sink endpoint.
-* ``source_subr``: if only certain fields (a subrecord) of the source endpoint should be included in the connection, their names are listed in this parameter. The ``None`` value connects all fields.
-* ``sink_subr``: if the connection should only drive certain fields (a subrecord) of the sink endpoint, they are listed here. The ``None`` value connects all fields.
-
-Migen's ``DataFlowGraph`` class implements a method that makes it easy to add actor connections to a graph: ::
-
- add_connection(source_node, sink_node,
- source_ep=None, sink_ep=None, # default: assume nodes have 1 source/sink
- # and use that one
- source_subr=None, sink_subr=None) # default: use whole record
-
-Abstract and physical networks
-==============================
-
-A network (or graph) is abstract if it cannot be physically implemented by only connecting existing records together. More explicitly, a graph is abstract if any of these conditions is met:
-
-#. A node is an abstract actor.
-#. A subrecord is used at a source or a sink.
-#. A single source feeds more than one sink.
-
-The ``DataFlowGraph`` class implements a method ``is_abstract`` that tests and returns if the network is abstract.
-
-An abstract graph can be turned into a physical graph through *elaboration*.
-
-Elaboration
-===========
-
-The most straightforward elaboration process goes as follows:
-
-#. Whenever several sources drive different fields of a single sink, insert a ``Combinator`` plumbing actor. A ``Combinator`` should also be inserted when a single source drive only certain fields of a sink.
-#. Whenever several sinks are driven by a single source (possibly by different fields of that source), insert a ``Splitter`` plumbing actor. A ``Splitter`` should also be inserted when only certain fields of a source drive a sink.
-#. Whenever an actor is abstract, instantiate it.
-
-This method is implemented by default by the ``elaborate`` method of the ``DataFlowGraph`` class, that modifies the graph in-place.
-
-Thanks to abstract actors, there are optimization possibilities during this stage:
-
-* Time-sharing an actor to reduce resource utilization.
-* Duplicating an actor to increase performance.
-* Promoting an actor to a wider datapath to enable time-sharing with another. For example, if a network contains a 16-bit and a 32-bit multiplier, the 16-bit multiplier can be promoted to 32-bit and time-shared.
-* Algebraic optimizations.
-* Removing redundant actors whose output is only used partially. For example, two instances of divider using the restoring method can be present in a network, and each could generate either the quotient or the remainder of the same integers. Since the restoring method produces both results at the same time, only one actor should be used instead.
-
-None of these optimizations are implemented yet.
-
-Implementation
-==============
-
-A physical graph can be implemented and turned into a synthesizable or simulable fragment using the ``migen.flow.network.CompositeActor`` actor.
-
-Performance tools
-*****************
-
-The module ``migen.flow.perftools`` provides utilities to analyze the performance of a dataflow network.
-
-The class ``EndpointReporter`` is a simulation object that attaches to an endpoint and measures three parameters:
-
-* The total number of clock cycles per token (CPT). This gives a measure of the raw inverse token rate through the endpoint. The smaller this number, the faster the endpoint operates. Since an endpoint has only one set of synchronous control signals, the CPT value is always superior or equal to 1 (multiple data records can however be packed into a single token, see for example :ref:`structuring`).
-* The average number of inactivity cycles per token (IPT). An inactivity cycle is defined as a cycle with the ``stb`` signal deasserted. This gives a measure of the delay between attempts at token transmissions ("slack") on the endpoint.
-* The average number of stall cycles per token (NPT). A stall cycle is defined as a cycle with ``stb`` asserted and ``ack`` deasserted. This gives a measure of the "backpressure" on the endpoint, which represents the average number of wait cycles it takes for the source to have a token accepted by the sink. If all tokens are accepted immediately in one cycle, then NPT=0.
-
-In the case of an actor network, the ``DFGReporter`` simulation object attaches an ``EndpointReporter`` to the source endpoint of each edge in the graph. The graph must not be abstract.
-
-The ``DFGReporter`` contains a dictionary ``nodepair_to_ep`` that is keyed by ``(source actor, destination actor)`` pairs. Entries are other dictionaries that are keyed with the name of the source endpoint and return the associated ``EndpointReporter`` objects.
-
-``DFGReporter`` also provides a method ``get_edge_labels`` that can be used in conjunction with NetworkX's [networkx]_ ``draw_networkx_edge_labels`` function to draw the performance report on a graphical representation of the graph (for an example, see :ref:`get_edge_labels`).
-
-.. [networkx] http://networkx.lanl.gov/
-
-.. _get_edge_labels:
-
-.. figure:: get_edge_labels.png
- :scale: 55 %
-
- Actor network with performance data from a simulation run.
-
-
-High-level actor description
-****************************
-
-Actors can be written in a subset of Python and automatically compiled into FHDL by using the Pytholite component. This functionality is still very limited for now.
-The FHDL layer
-##############
+The FHDL domain-specific language
+#################################
-The Fragmented Hardware Description Language (FHDL) is the lowest layer of Migen. It consists of a formal system to describe signals, and combinatorial and synchronous statements operating on them. The formal system itself is low level and close to the synthesizable subset of Verilog, and we then rely on Python algorithms to build complex structures by combining FHDL elements.
+The Fragmented Hardware Description Language (FHDL) is the basis of Migen. It consists of a formal system to describe signals, and combinatorial and synchronous statements operating on them. The formal system itself is low level and close to the synthesizable subset of Verilog, and we then rely on Python algorithms to build complex structures by combining FHDL elements.
The FHDL module also contains a back-end to produce synthesizable Verilog, and some structure analysis and manipulation functionality.
FHDL differs from MyHDL [myhdl]_ in fundamental ways. MyHDL follows the event-driven paradigm of traditional HDLs (see :ref:`background`) while FHDL separates the code into combinatorial statements, synchronous statements, and reset values. In MyHDL, the logic is described directly in the Python AST. The converter to Verilog or VHDL then examines the Python AST and recognizes a subset of Python that it translates into V*HDL statements. This seriously impedes the capability of MyHDL to generate logic procedurally. With FHDL, you manipulate a custom AST from Python, and you can more easily design algorithms that operate on it.
Signal
======
+
The signal object represents a value that is expected to change in the circuit. It does exactly what Verilog's "wire" and "reg" and VHDL's "signal" do.
The main point of the signal object is that it is identified by its Python ID (as returned by the :py:func:`id` function), and nothing else. It is the responsibility of the V*HDL back-end to establish an injective mapping between Python IDs and the V*HDL namespace. It should perform name mangling to ensure this. The consequence of this is that signal objects can safely become members of arbitrary Python classes, or be passed as parameters to functions or methods that generate logic involving them.
Operators
=========
+
Operators are represented by the ``_Operator`` object, which generally should not be used directly. Instead, most FHDL objects overload the usual Python logic and arithmetic operators, which allows a much lighter syntax to be used. For example, the expression: ::
a * b + c
Slices
======
+
Likewise, slices are represented by the ``_Slice`` object, which often should not be used in favor of the Python slice operation [x:y]. Implicit indices using the forms [x], [x:] and [:y] are supported. Beware! Slices work like Python slices, not like VHDL or Verilog slices. The first bound is the index of the LSB and is inclusive. The second bound is the index of MSB and is exclusive. In V*HDL, bounds are MSB:LSB and both are inclusive.
Concatenations
==============
+
Concatenations are done using the ``Cat`` object. To make the syntax lighter, its constructor takes a variable number of arguments, which are the signals to be concatenated together (you can use the Python "*" operator to pass a list instead).
To be consistent with slices, the first signal is connected to the bits with the lowest indices in the result. This is the opposite of the way the "{}" construct works in Verilog.
Replications
============
+
The ``Replicate`` object represents the equivalent of {count{expression}} in Verilog.
Statements
Assignment
==========
+
Assignments are represented with the ``_Assign`` object. Since using it directly would result in a cluttered syntax, the preferred technique for assignments is to use the ``eq()`` method provided by objects that can have a value assigned to them. They are signals, and their combinations with the slice and concatenation operators.
As an example, the statement: ::
If
==
+
The ``If`` object takes a first parameter which must be an expression (combination of the ``Constant``, ``Signal``, ``_Operator``, ``_Slice``, etc. objects) representing the condition, then a variable number of parameters representing the statements (``_Assign``, ``If``, ``Case``, etc. objects) to be executed when the condition is verified.
The ``If`` object defines a ``Else()`` method, which when called defines the statements to be executed when the condition is not true. Those statements are passed as parameters to the variadic method.
Case
====
+
The ``Case`` object constructor takes as first parameter the expression to be tested, and a dictionary whose keys are the values to be matched, and values the statements to be executed in the case of a match. The special value ``"default"`` can be used as match value, which means the statements should be executed whenever there is no other match.
Arrays
======
+
The ``Array`` object represents lists of other objects that can be indexed by FHDL expressions. It is explicitly possible to:
* nest ``Array`` objects to create multidimensional tables.
Tri-state I/O
=============
+
A triplet (O, OE, I) of one-way signals defining a tri-state I/O port is represented by the ``TSTriple`` object. Such objects are only containers for signals that are intended to be later connected to a tri-state I/O buffer, and cannot be used as module specials. Such objects, however, should be kept in the design as long as possible as they allow the individual one-way signals to be manipulated in a non-ambiguous way.
The object that can be used in as a module special is ``Tristate``, and it behaves exactly like an instance of a tri-state I/O buffer that would be defined as follows: ::
Instances
=========
+
Instance objects represent the parametrized instantiation of a V*HDL module, and the connection of its ports to FHDL signals. They are useful in a number of cases:
* Reusing legacy or third-party V*HDL code.
Memories
========
+
Memories (on-chip SRAM) are supported using a mechanism similar to instances.
A memory object has the following parameters:
Summary of special attributes
=============================
-.. table:: Summary of special attributes
+.. table::
+--------------------------------------------+--------------------------------------------------------------+
| Syntax | Action |
The clock domain management mechanism explained above happens during finalization.
-Simulation
-==========
-
-The ``do_simulation`` method of the ``Module`` class can be defined and will be executed at each clock cycle, or the generator-style API can be used by defining ``gen_simulation`` instead. The generator yields the number of cycles it wants to wait for. See :ref:`simulating` for more information on using the simulator.
-
-Simulation of designs with several clock domains is not supported yet.
-
Conversion for synthesis
************************
-Any FHDL module (except, of course, its simulation functions) can be converted into synthesizable Verilog HDL. This is accomplished by using the ``convert`` function in the ``verilog`` module.
+Any FHDL module can be converted into synthesizable Verilog HDL. This is accomplished by using the ``convert`` function in the ``verilog`` module.
-The Mibuild component provides scripts to interface third-party FPGA tools to Migen and a database of boards for the easy deployment of designs.
+The ``migen.build`` component provides scripts to interface third-party FPGA tools (from Xilinx, Altera and Lattice) to Migen, and a database of boards for the easy deployment of designs.
introduction
fhdl
- bus
- dataflow
simulation
- casestudies
- api
+ synthesis
+ reference
Background
**********
-Even though the Milkymist system-on-chip [mm]_ is technically successful, it suffers from several limitations stemming from its implementation in manually written Verilog HDL:
+Even though the Milkymist system-on-chip [mm]_ had many successes, it suffers from several limitations stemming from its implementation in manually written Verilog HDL:
.. [mm] http://m-labs.hk
****************
Either run the ``setup.py`` installation script or simply set ``PYTHONPATH`` to the root of the source directory.
-For simulation support, an extra step is needed. See :ref:`vpisetup`.
-
If you wish to contribute patches, the suggest way to install is;
#. Clone from the git repository at http://github.com/m-labs/migen
#. Install using ``python3 ./setup.py develop --user``
Alternative install methods
===========================
- * Migen is available for linux-64 and linux-32 through Binstar's conda tool. Instructions are at https://binstar.org/fallen/migen
- * Migen can be referenced in a requirements.txt file (used for ``pip install -r requirements.txt``) via ``-e git+http://github.com/m-labs/migen.git#egg=migen``. See the `pip documentation <https://pip.pypa.io/en/latest/reference/pip_install.html#id19>`_ for more information.
+ * Migen is available for the Anaconda Python distribution. The package can be found at at https://anaconda.org/m-labs/migen
+ * Migen can be referenced in a requirements.txt file (used for ``pip install -r requirements.txt``) via ``-e git+http://github.com/m-labs/migen.git#egg=migen``. See the pip documentation for more information.
Feedback
********
-Feedback concerning Migen or this manual should be sent to the M-Labs developers' mailing list at devel@lists.m-labs.hk.
+Feedback concerning Migen or this manual should be sent to the M-Labs developers' mailing list ``devel`` on lists.m-labs.hk.
--- /dev/null
+API reference
+=============
+
+:mod:`fhdl.structure` module
+----------------------------
+
+.. automodule:: migen.fhdl.structure
+ :members:
+ :show-inheritance:
+
+:mod:`fhdl.bitcontainer` module
+-------------------------------
+
+.. automodule:: migen.fhdl.bitcontainer
+ :members:
+ :show-inheritance:
+
+:mod:`genlib.fifo` module
+-------------------------
+
+.. automodule:: migen.genlib.fifo
+ :members:
+ :show-inheritance:
+
+:mod:`genlib.coding` module
+---------------------------
+
+.. automodule:: migen.genlib.coding
+ :members:
+ :show-inheritance:
+
+:mod:`genlib.sort` module
+-------------------------
+
+.. automodule:: migen.genlib.sort
+ :members:
+ :show-inheritance:
-.. _simulating:
-
Simulating a Migen design
#########################
Migen allows you to easily simulate your FHDL design and interface it with arbitrary Python code.
-To interpret the design, the FHDL structure is simply converted into Verilog and then simulated using an external program (e.g. Icarus Verilog). This is is intrinsically compatible with VHDL/Verilog instantiations from Migen and maximizes software reuse.
-
-To interface the external simulator to Python, a VPI task is called at each clock cycle and implement the test bench functionality proper - which can be fully written in Python.
-
-Signals inside the simulator can be read and written using VPI as well. This is how the Python test bench generates stimulus and obtains the values of signals for processing.
-
-.. _vpisetup:
-
-Installing the VPI module
-*************************
-
-To communicate with the external simulator, Migen uses a UNIX domain socket and a custom protocol which is handled by a VPI plug-in (written in C) on the simulator side.
-
-To build and install this plug-in, run the following commands from the ``vpi`` directory: ::
-
- make [INCDIRS=-I/usr/...]
- make install [INSTDIR=/usr/...]
-
-The variable ``INCDIRS`` (default: empty) can be used to give a list of paths where to search for the include files. This is useful considering that different Linux distributions put the ``vpi_user.h`` file in various locations.
-
-The variable ``INSTDIR`` (default: ``/usr/lib/ivl``) specifies where the ``migensim.vpi`` file is to be installed.
-
-This plug-in is designed for Icarus Verilog, but can probably be used with most Verilog simulators with minor modifications.
-
-The generic simulator object
-****************************
-
-The generic simulator object (``migen.sim.generic.Simulator``) is the central component of the simulation.
-
-Creating a simulator object
-===========================
-
-The constructor of the ``Simulator`` object takes the following parameters:
-
-#. The module to simulate.
-#. A top-level object (see :ref:`toplevel`). With the default value of ``None``, the simulator creates a default top-level object itself.
-#. A simulator runner object (see :ref:`simrunner`). With the default value of ``None``, Icarus Verilog is used with the default parameters.
-#. The name of the UNIX domain socket used to communicate with the external simulator through the VPI plug-in (default: "simsocket").
-#. Additional keyword arguments (if any) are passed to the Verilog conversion function.
-
-For proper initialization and clean-up, the simulator object should be used as a context manager, e.g. ::
-
- with Simulator(tb) as s:
- s.run()
-
-Running the simulation
-======================
-
-Running the simulation is achieved by calling the ``run`` method of the ``Simulator`` object.
-
-It takes an optional parameter ``ncycles`` that defines the maximum number of clock cycles that this call simulates. The default value of ``None`` sets no cycle limit.
-
-The cycle counter
-=================
-
-Simulation functions can read the current simulator cycle by reading the ``cycle_counter`` property of the ``Simulator``. The cycle counter's value is 0 for the cycle immediately following the reset cycle.
-
-Simplified simulation set-up
-============================
-
-Most simulations are run in the same way and do not need the slightly heavy syntax needed to create and run a Simulator object. There is a function that exposes the most common features with a simpler syntax: ::
-
- run_simulation(module, ncycles=None, vcd_name=None, keep_files=False)
-
-Module-level simulation API
-***************************
-
-Simulation functions and generators
-===================================
-
-Whenever a ``Module`` declares a ``do_simulation`` method, it is executed at each cycle and can manipulate values from signal and memories (as explained in the next section).
-
-Instead of defining such a method, ``Modules`` can declare a ``gen_simulation`` generator that is initialized at the beginning of the simulation, and yields (usually multiple times) to proceed to the next simulation cycle.
-
-Simulation generators can yield an integer in order to wait for that number of cycles, or yield nothing (``None``) to wait for 1 cycle.
-
-Reading and writing values
-===========================
-
-Simulation functions and generators take as parameter a special object that gives access to the values of the signals of the current module using the regular Python read/write syntax. Nested objects, lists and dictionaries containing signals are supported, as well as Migen memories, for reading and writing.
-
-Here are some examples: ::
-
- def do_simulation(self, selfp):
- selfp.foo = 42
- self.last_foo_value = selfp.foo
- selfp.dut.banks[2].bar["foo"] = 1
- self.last_memory_data = selfp.dut.mem[self.memory_index]
-
-The semantics of reads and writes (respectively immediately before and after the clock edge) match those of the non-blocking assignment in Verilog. Note that because of Verilog's design, reading "variable" signals (i.e. written to using blocking assignment) directly may give unexpected and non-deterministic results and is not supported. You should instead read the values of variables after they have gone through a non-blocking assignment in the same ``always`` block.
-
-Those constructs are syntactic sugar for calling the ``Simulator`` object's methods ``rd`` and ``wr``, that respectively read and write data from and to the simulated design. The simulator object can be accessed as ``selfp.simulator``, and for special cases it is sometimes desirable to call the lower-level methods directly.
-
-The ``rd`` method takes the FHDL ``Signal`` object to read and returns its value as a Python integer. The returned integer is the value of the signal immediately before the clock edge.
-
-The ``wr`` method takes a ``Signal`` object and the value to write as a Python integer. The signal takes the new value immediately after the clock edge.
-
-References to FHDL ``Memory`` objects can also be passed to the ``rd`` and ``wr`` methods. In this case, they take an additional parameter for the memory address.
-
-Simulation termination management
-=================================
-
-Simulation functions and generators can raise the ``StopSimulation`` exception. It is automatically raised when a simulation generator is exhausted. This exception disables the current simulation function, i.e. it is no longer run by the simulator. The simulation is over when all simulation functions are disabled (or the specified maximum number of cycles, if any, has been reached - whichever comes first).
-
-Some simulation modules only respond to external stimuli - e.g. the ``bus.wishbone.Tap`` that snoops on bus transactions and prints them on the console - and have simulation functions that never end. To deal with those, the new API introduces "passive" simulation functions that are not taken into account when deciding to continue to run the simulation. A simulation function is declared passive by setting a "passive" attribute on it that evaluates to True. Raising ``StopSimulation`` in such a function still makes the simulator stop running it for the rest of the simulation.
-
-When starting the simulation of a design that contains no simulation functions or only passive simulation functions, the simulation will continue until the specified number of cycles is reached. The ``ncycles`` parameter is mandatory in this case.
-
-.. _simrunner:
-
-The external simulator runner
-*****************************
-
-Role
-====
-
-The runner object is responsible for starting the external simulator, loading the VPI module, and feeding the generated Verilog into the simulator.
-
-It must implement a ``start`` method, called by the ``Simulator``, which takes two strings as parameters. They contain respectively the Verilog source of the top-level design and the converted module.
-
-Icarus Verilog support
-======================
-
-Migen comes with a ``migen.sim.icarus.Runner`` object that supports Icarus Verilog.
-
-Its constructor has the following optional parameters:
-
-#. ``extra_files`` (default: ``None``): lists additional Verilog files to simulate.
-#. ``top_file`` (default: "migensim_top.v"): name of the temporary file containing the top-level.
-#. ``dut_file`` (default: "migensim_dut.v"): name of the temporary file containing the converted fragment.
-#. ``vvp_file`` (default: ``None``): name of the temporary file compiled by Icarus Verilog. When ``None``, becomes ``dut_file + "vp"``.
-#. ``keep_files`` (default: ``False``): do not delete temporary files. Useful for debugging.
-
-.. _toplevel:
-
-The top-level object
-********************
-
-Role of the top-level object
-============================
-
-The top-level object is responsible for generating the Verilog source for the top-level test bench.
-
-It must implement a method ``get`` that takes as parameter the name of the UNIX socket the VPI plugin should connect to, and returns the full Verilog source as a string.
-
-It must have the following attributes (which are read by the ``Simulator`` object):
-
-* ``clk_name``: name of the clock signal.
-* ``rst_name``: name of the reset signal.
-* ``dut_type``: module type of the converted fragment.
-* ``dut_name``: name used for instantiating the converted fragment.
-* ``top_name``: name/module type of the top-level design.
-
-Role of the generated Verilog
-=============================
-
-The generated Verilog must:
-
-#. instantiate the converted fragment and connect its clock and reset ports.
-#. produce a running clock signal.
-#. assert the reset signal for the first cycle and deassert it immediately after.
-#. at the beginning, call the task ``$migensim_connect`` with the UNIX socket name as parameter.
-#. at each rising clock edge, call the task ``$migensim_tick``. It is an error to call ``$migensim_tick`` before a call to ``$migensim_connect``.
-#. set up the optional VCD output file.
-
-The generic top-level object
-============================
-
-Migen comes with a ``migen.sim.generic.TopLevel`` object that implements the above behaviour. It should be usable in the majority of cases.
-
-The main parameters of its constructor are the output VCD file (default: ``None``) and the levels of hierarchy that must be present in the VCD (default: 1).
+[To be rewritten]
--- /dev/null
+Synthesizing a Migen design
+###########################
+
+[To be written]
setup(
name="migen",
- version="0.0+dev",
+ version="1.0",
description="Python toolbox for building complex digital hardware",
long_description=README,
author="Sebastien Bourdeauducq",
projects / litex.git / commitdiff
