-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support silkscreen references (and other information) in platform definitions #143
Comments
How would it be presented to the user? |
I would suggest that the;
Then you could do something like; leds = {}
while True:
l = platform.get_resource("user_led")
if not l:
break
leds[l.silkscreen_reference or 'led{}'.format(len(leds))] = l
self.gpio = GPIO(len(leds))
for i, (name, l) in enumerate(sort(leds.items())):
m.d.sync += l.eq(self.gpio.reg[i])
if l.silkscreen_reference:
m.define('USER_LED{}'.format(i), l.silkscreen_reference) |
What is |
Was thinking something like class BaseSoC(SoCSDRAM):
def __init__(self, platform, **kwargs):
self.add_constant("SPIFLASH_PAGE_SIZE", platform.spiflash_page_size)
self.add_constant("SPIFLASH_SECTOR_SIZE", platform.spiflash_sector_size) |
That doesn't explain what it does. |
Provides a define in the C header file. CSRConstant could be another option. Or you could write out a CSV or other configuration file? |
Writing C header files is definitely not something that should be a part of core nMigen. |
I agree that the output side probably doesn't make sense in nMigen's core -- was just trying to provide some type of example of how it might end up getting used. As this information tends to end up in comments in the board / platform file anyway, it seems a good idea to allow a more structured format that other tools can then use / depend on? I also can't think of a logical way for this information to be provided in an external file / package while still being kept in sync with the board files. Do you have any ideas? My thinking is kind of like how type hints don't /do/ anything in Python directly but other tools can reuse them. Type hints kind of came out of people putting the information in their numpy / Google style docstrings too... Open to alternative suggestions / proposals..... |
We should definitely have the ability to add refres information to resources. Perhaps I am not so sure about the |
I like Silk over Refdes (I assume Reference Designator)? Something like a freeform |
The main problem here is to decide what can they be attached, what is the syntax for that, and how should they be retrieved. It's hard to see this just from hypotheticals, and without a concrete use case. |
These example comments in the litex-buildenv Opsis platform definition would be candidates to end up in docstring type stuff in my opinion; ## Opsis I2C Bus
# Connected to both the EEPROM and the FX2.
#
## 24AA02E48 - component U23
# 2 Kbit Electrically Erasable PROM
# Pre-programmed Globally Unique, 48-bit Node Address
# The device is organized as two blocks of 128 x 8-bit memory with a 2-wire serial interface.
## \/ Strongly pulled (2k) to VCC3V3 via R34
#NET "eeprom_scl" LOC = "G6" |IOSTANDARD = I2C; # (/Ethernet/MAC_SCL)
#NET "eeprom_sda" LOC = "C1" |IOSTANDARD = I2C; # (/Ethernet/MAC_SDA)
("opsis_i2c", 0,
Subsignal("scl", Pins("G6"), IOStandard("I2C")),
Subsignal("sda", Pins("C1"), IOStandard("I2C")),
),
## DDR3
# MT41J128M16JT-125:K - 16 Meg x 16 x 8 Banks - DDR3-1600 11-11-11
# FBGA Code: D9PSL, Part Number: MT41J128M16 - http://www.micron.com/support/fbga
("ddram_clock", 0,
Subsignal("p", Pins("K4")),
Subsignal("n", Pins("K3")),
IOStandard("DIFF_SSTL15_II"), Misc("IN_TERM=NONE")
),
("ddram", 0,
Subsignal("cke", Pins("F2"), IOStandard("SSTL15_II")),
Subsignal("ras_n", Pins("M5"), IOStandard("SSTL15_II")),
Subsignal("cas_n", Pins("M4"), IOStandard("SSTL15_II")),
Subsignal("we_n", Pins("H2"), IOStandard("SSTL15_II")),
Subsignal("ba", Pins("J3 J1 H1"), IOStandard("SSTL15_II")),
Subsignal("a", Pins("K2 K1 K5 M6 H3 L4 M3 K6 G3 G1 J4 E1 F1 J6 H5"), IOStandard("SSTL15_II")),
Subsignal("dq", Pins(
"R3 R1 P2 P1 L3 L1 M2 M1",
"T2 T1 U3 U1 W3 W1 Y2 Y1"), IOStandard("SSTL15_II")),
Subsignal("dqs", Pins("N3 V2"), IOStandard("DIFF_SSTL15_II")),
Subsignal("dqs_n", Pins("N1 V1"), IOStandard("DIFF_SSTL15_II")),
Subsignal("dm", Pins("N4 P3"), IOStandard("SSTL15_II")),
Subsignal("odt", Pins("L6"), IOStandard("SSTL15_II")),
Subsignal("reset_n", Pins("E3"), IOStandard("LVCMOS15")),
Misc("SLEW=FAST"),
Misc("VCCAUX_IO=HIGH")
),
## onboard HDMI IN1
## HDMI - connector J5 - Direction RX
("hdmi_in", 0,
Subsignal("clk_p", Pins("L20"), IOStandard("TMDS_33")),
Subsignal("clk_n", Pins("L22"), IOStandard("TMDS_33")),
Subsignal("data0_p", Pins("M21"), IOStandard("TMDS_33")),
Subsignal("data0_n", Pins("M22"), IOStandard("TMDS_33")),
Subsignal("data1_p", Pins("N20"), IOStandard("TMDS_33")),
Subsignal("data1_n", Pins("N22"), IOStandard("TMDS_33")),
Subsignal("data2_p", Pins("P21"), IOStandard("TMDS_33")),
Subsignal("data2_n", Pins("P22"), IOStandard("TMDS_33")),
Subsignal("scl", Pins("T21"), IOStandard("LVCMOS33")),
Subsignal("sda", Pins("R22"), IOStandard("LVCMOS33")),
Subsignal("hpd_en", Pins("R20"), IOStandard("LVCMOS33"))
),
## onboard HDMI IN2
## HDMI - connector J4 - Direction RX
("hdmi_in", 1,
Subsignal("clk_p", Pins("M20"), IOStandard("TMDS_33")),
Subsignal("clk_n", Pins("M19"), IOStandard("TMDS_33")),
Subsignal("data0_p", Pins("J20"), IOStandard("TMDS_33")),
Subsignal("data0_n", Pins("J22"), IOStandard("TMDS_33")),
Subsignal("data1_p", Pins("H21"), IOStandard("TMDS_33")),
Subsignal("data1_n", Pins("H22"), IOStandard("TMDS_33")),
Subsignal("data2_p", Pins("K20"), IOStandard("TMDS_33")),
Subsignal("data2_n", Pins("L19"), IOStandard("TMDS_33")),
Subsignal("scl", Pins("L17"), IOStandard("LVCMOS33")),
Subsignal("sda", Pins("T18"), IOStandard("LVCMOS33")),
Subsignal("hpd_en", Pins("V19"), IOStandard("LVCMOS33"))
), The Maybe we should do some more conversion of the the Opsis / Atlys board files and see if we can shake something out? The Atlys board porting is already were the idea of Silk / Designators kind of came from. |
Alright. I'll see what I can do about this. |
Not directly silkscreen data but another idea I had is to provide possibility of having a picture of a board (attached to|included in) a Platform class. |
@Fatsie That is something I have wanted to do for a long time too. However, I feel like that is better done through creating a file format which is something like a collection of image files + XML/JSON description of were things are. If that file format also had silk references it would be easy to connect the nMigen platform and the file together in a GUI / emulation environment? |
@mithro |
@Fatsie - I think the images + connector (+button+led) locations information would be useful for tools like @renode and QEmu -- not just nmigen. It is also likely that only a small number of boards which are used in nmigen will ever get this information -- hence why I'm thinking they should be separate.... |
That seems extremely prone to desynchronization. |
The new Atlys platform definition in #15 does the following;
It would be really useful to expose the information in the comments to a user.
I think this makes the most sense for LEDs and switches, but can work for connectors too.
With this information you could even then write something which lets you specify silk screen reference values in a console and have them mapped to the right switch / led.
For the complicated boards like the Digilent Atlys we went even further and provided the following;
I feel like this information should be in some type of docstring associated with connectors / resources?
The text was updated successfully, but these errors were encountered: