SimpCon
From JopWiki
Simpcon is the main SoC interconnect in JOP. After trying Wishbone and Avalon with the resulting issues a SoC interconnection for pipelined transaction was developed. The main features are:
- Single cycle transaction start
- Early acknowledgement of transaction finish
- with a ready counter
- start the master pipeline earlier
- Pipelined transactions
Contents |
[edit] Specification
The SimpCon specification is open-source and available with examples from http://www.opencores.org/projects.cgi/web/simpcon/overview
[edit] Implementing Simpcon Peripherals in JOP
In any particular JOP sytem, by convention there is exactly one Simpcon peripheral multiplexer and one or more Simpcon peripherals. The Simpcon multiplexer is defined in a module named scio_xxx.vhd, where "xxx" is an identifier for the particular JOP system. For example, a JOP system targeted for the Spartan 3E starter kit will have one such module, and the module might be named scio_s3Esk.vhd.
Each individual peripheral type is by convention defined in its own module. By convention, a peripheral module is named sc_xxx.vhd, where xxx is the name of the peripheral type. For example, a UART peripheral might be named sc_uart.vhd. You create a new peripheral type by creating a new sc_xxx.vhd module. If your peripheral type might be of general use, you may want to generalize it using the VHDL "generic" construct.
Any given JOP system may have many peripherals and may instantiate more than one peripheral of the same type. For example, a system for a Spartan 3E starter kit may have two UARTs.
By convention, all peripherals for a particular JOP system are instantiated in the scio_xxx.vhd module for that system. The scio_xxx.vhd module will itself be instantiated in the top module for the system. The scio_xxx.vhd module will define a set of ports for the Simpccn interface, and a set of ports for the actual physical IO pins of each instantiated peripheral. The top module will connect the Simpcon interface to the JOP core, and will connect all of the actual peripheral ports to IO pins. As always, your top module will have its ports connects to actual FPGA pins ( for hardware synthesis) or will itself be instantiated within a testbench module (for simulation).
The scio_xxx.vhd module specifies the base address fro the peripheral address apace: this is by convention 0xffffff80, or -0x80. scio_min also speifies (as a power of 2) the number of addresses for each peripheral all peripherals get teh same number of addresses in current implementations of scio_xxx.vhd, and that number is sixteen, so there are at most eight peripherals. the first peripheral has addresses -0x80 through -0x8f, the next peripheral has addresses -0x70 through -0x7f. Within scio_xxx.vhd, the peripherals addresses are not explicit. Instead, each peripheral is instantiated with an index number (from 0 to 7 in current implementations.) The peripheral's address is the index times the number of addresses per peripheral, added to the base address. Thus, the peripheral at index 1 has address -0x80+(1*(0x10)=-0x70.
[edit] Peripherals for a New JOP System
If you want to port JOP to a new target, you should start by copying a system that is generally similar to yours as an example. You will then identify the differences in the I/O pins between the example system and your target system, and change your top_xxx.vhd to match. For the peripheal pins you intend to use, propagate the signals to the instance of your scio_xxx.vhd instance.
Next, write your scio_xxx.vhd module by adapting the one from the example. Your scio multiplexer will instantiate the peripherals you need, which may be more or less than those of your example. You will probably be able to use (or adapt) peripherals that already exist in JOP. If you adapt an existing peripheral, please consider making it generic if it makes sense to do so.
[edit] Simulation
If you creata a new peripheral controller, you are not finished until you write a simulator for your peripheral. Name the simulated peripheral sim_xxx.vhd and provide at least a crude simulation of the expected behavior. You may be able to find a simulation of your peripheral on the net somewhere.
[edit] Discussion
When this page contains more info on SimpCon we'll move this section to the discussion page.
The signal `sel_bytes' should probably go from the "reserved for future versions" state into the actual specification. The signal is essential for byte-wise write access and in my opinion it would be better to standardize this than relying on ad-hoc solutions to address this kind of access.
- good point, will add this Martin 01:27, 19 April 2007 (CDT)
The specification does not explicitly state whether the data bytes in SimpCon are meant to be little-endian or big-endian. The approach of zeroing-out/ignoring the "higher" bits would suggest little-endianness, so this probably should be made explicit.
- mmh, do we need to specify this at the interconnect level? For me it's clear which bit ends at which data line on a RAM. It is probably an issue for peripheral devices with less than 32 bit or when bit pattern for registers are specified. There the endianess is important. We should look into other specs. (e.g. Wishbone) how they handle this. Martin 01:27, 19 April 2007 (CDT)
- The Wishbone specification requires that the datasheet of a component states whether it is big- or little-endian and that conversion logic is added if necessary. The conversion is essentially for free -- but in my opinion it is easier to let the creator of a component apply the conversion than the user, which needs to read through the datasheets to get components match together. JeuneS2 10:36, 18 May 2007 (CDT)
A signal `error' from the slave to the master could help the reuse of components. If invalid access (e.g. write-access to a ROM) gets signaled instead of ignored (as the currently available signals suggest), misuse of components can be detected far more easily.
- good point, will be added Martin 01:27, 19 April 2007 (CDT)
The documentation talks about registering the address for master multiplexing. Does there exist code to implement this in the case of pipelined access or is this to be done?
--JeuneS2 17:57, 18 April 2007 (CDT)
