orangecrab-fpga / orangecrab-hardware Goto Github PK

On trying to open the 0.2.1 schematics, I get The project symbol library cache file 'OrangeCrab-cache. lib' was not found.. Opening the schematic anyway results in broken symbols. 0.2 schematic works with no issues, besides a few things related to upgrading to a new kicad version.

I've started working on some Docs, but these need to be improved/extended.

https://gregdavill.github.io/OrangeCrab/r0.2/

• Geting started guide, (tool-chain install to first blinky?)
• What Next (example projects/ideas)
• Step-by-Step Guide to installing Linux on the Crab.
• Get microPython/Circuit python working. (Branch from Fomu port?)

Anything else I've missed?

A design review of the DDR3L layout was performed (Unfortunately after I'd ordered r0.1 prototypes). It identified some points that should be easy to address.

The pinout of the DDR3 IC schematic symbol is confusing.
One pin represents 9(!) pads in the real package

I want to avoid having hundreds of GND/PWR connections on the schematic, so I'm thinking if we re-name the pins using "KiPart" notation GND [9] to denote 9 physical pins are connected to the 1 schematic pin.

The tracerouting is too tight. The space between RAM_A0 and RAM_A3 is only 3.54 mil (see the attachment "tight_tracerouting.png")
The document "TN-46-14: Hardware Tips for Point-to-Point System Design Introduction" suggests space between address traces at least 6 mil.
(Please take a look at the "Trace Width (S3) Design Guidelines" chapter)

To achieve this spacing we can route signals on L1 and L3, which share L2 as a reference ground plane.

The power delivery network could be optimized. (see the attachment "power_delivery_network.png")
The trace shown in the attachment is to narrow, and could be at least 1.5 times wider.
The same rule could/should be applied to all the power/ground nets on the top layer.

This can be done a new hardware rev.

Additionally adding 3 more address pins means we can support upto 8Gb DDR3L chips, right now due to address routing we only support 1Gb parts.

Brightness for all the LEDs needs to be tuned.

Currently the charge LED is much brighter than the user LED.

@pdp7 has commented on the prototype r0.2 board he's got:

the crab gets quite hot to the touch when running litex vexriscv... is that expected?

I've noticed this too with my testing, the SDRAM seems to run ~10-20°C above ambient. This can make for a very toasty board, although this shouldn't cause any part failures. I'm curious if this is just normal for DDR3L, or if LiteDRAM is keeping the bus in an active state during times of inactivity.

I will throw a unit under a thermal camera to see exactly where the heat is coming from, I suspect the DDR3/ECP5 I/O drivers, the memory has On-Device-Termination. Which pulls the DQ pins to VDD/2 via ~60Ohms. And also all the Address and Control lines have 50Ohm termination to VDD/2. I suspect this is what's heating up.

Lots of devices make use DDR memory, and they're not burning hot while idle, so maybe there is a way we can tri-state the bus while idle in LiteDRAM to avoid this power wastage/heat.

Please tell me if I should create this issue somewhere else.

I remember you controlled the LED with PWM driver in Linux.

Could you share the commands you used?

thanks!

With the production run of r0.2 boards complete. I've got some ideas for adjusting the designs to improve the test workflow, and optimise the BOM (With the goal of reducing the total unit cost)

These are ideas slated for r0.2.1, There shall be no electrical/pin changes to the FPGA/DDR3.
With my versioning convention any gateware/examples for r0.2 should work on r0.2.1.

To improve the testing procedures:

• Add larger test-points for USB connection, enabling the tests/programming to occur without plugging USB in.
• Add test-points for JTAG, so we avoid plugging in the JTAG connection every time.

BOM optimisations:

• Evaluate swapping DCDC regulators from WLCSP to DFN/SOT (Lower cost, lower assembly cost)
• Remove JTAG connector in favor of through-hole 0.05"/0.1" footprint (The Samtec 0.05" JTAG connector is quite expensive)
• Alter RGB LEDs used. (Ensure R,G,B mapping is kept identical)
• Remove VTT resistors, as they're not required for the scope of this design.
• Remove DDR VREF LDO, for 1-2 SDRAM chips a simple resistor divider is acceptable.

Other nice changes:

• USB-C? (Likely making use of a USB 2.0 type-C connector, see #18 )
• Panelisation changes to avoid any rough tabs left on board edges
• Castellated edges?

Feel free to add any extra comments or suggestions to this issue.

I am having some issues with the OrangeCrab variant 85F. When I program it I get the following:

$ dfu-util -D blink_reset.dfu
Match vendor ID from file: 1209
Match product ID from file: 5af0
dfu-util: More than one DFU capable USB device found! Try `--list' and specify the serial number or disconnect all but one device

(Note: using latest dfu-util version 0.11, provided by oss-cad-suite-build)

This is the corresponding device list:

$ dfu-util --list
Found DFU: [1209:5af0] ver=0101, devnum=7, cfg=1, intf=0, path="3-2", alt=1, name="0x00100000 RISC-V Firmware", serial="UNKNOWN"
Found DFU: [1209:5af0] ver=0101, devnum=7, cfg=1, intf=0, path="3-2", alt=0, name="0x00080000 Bitstream", serial="UNKNOWN"

If I select the "alternative 0" (dfu-util -a 0 -D blink_reset.dfu) everything works fine (modulo the error message in #37).

Litex/nmigen/etc., all assume that there is only one "device" (1209:5af0), so I understand this is not intended by design. If so, is this fixed in the last DFU bootloader? I may have received a unit with an outdated version.

Possibly useful: lsusb output.

Also, apparently, the 25F and 85F bitstreams are incompatible, but dfu-util will happily a bitstream, but the FPGA is stuck doing nothing until reset into DFU mode. This is especially frustrating as the toolchains hardcode 25F in them (I'll probably post some PRs once this is sorted out).
I would suggest using a separate USB PID, but of course, it is already too late and I understand PIDs are a scarce resource; so maybe there is a way to still convince dfu-util to refuse to upload it? (maybe iSerialNumber or in the iProduct string).

Hello,
I honestly really love your project (But for me 100$ is kinda steep)
and I wanted to know if it would be possible to setup a chatroom (probably discord)
for all things orangecrab related. (I doubt you haven't) but if you would like help setting it up
I can help, and I'm sure there are plenty here who can also help.
Well if you do want to do this, you are free to contact me at this post or at my discord
(Bennyturtle#7936), also If you wanted example projects, once I am able to get a board I can try
to make a few basic ones to show how it works, I am a very (very) small youtuber and could make a few videos explaining it

Hi @gregdavill,

I just got my hands on OrangeCrab and am looking to use the internal SPI flash within a LiteX SoC to store the BIOS + firmware.

I was wondering if the r0.2 as sold by GroupGets has the W25Q128JVPIQ SPI flash preconfigured with block/sector lock in order to protect the first 4Mbits of the bootloader.

Hello I am a FPGA developer

If you want to add your board to IceStudio you only have to send me one board, and I am glad to include the board in the supported list of boards of this IDE.

IceStudio is a visual editor for open FPGA boards
https://icestudio.io/

I have already added different boards with ECP5 Lattice Model to IceStudio
Colorlight boards --> FPGAwars/icestudio#500
FleaFPGA-Ohm ECP5 board --> FPGAwars/icestudio#521
and ECP-5 Evaluation Board --> FPGAwars/icestudio#541

My email is benitoss@gmail,com if you are interested

Rergards
Fernando

I noticed these two differential signals were swapped in the r0.2 schematic. I've never done a DDR design and was wondering if there was a reason for this or if it snuck in during layout?

Are there any examples of programming an OrangeCrab using the soft RISC-V core, but with custom "gateware" for hardware accelerated peripherals? My goal is to largely program using C/assembly, but to also extend the CPU core using Verilog.

In the RISC-V blinky example, I am confused as to where the RISC-V core actually resides. Is it part of the bootloader, which simply runs the (assembly) program stored in flash rather than reconfiguring the FPGA? Or is there a RISC-V core being pulled into the blinky example that becomes part of "custom" FPGA configuration which then runs the assembly code?

I'd appreciate it if you'd shed some light on this!

RPC DRAM from Etron reduces the pin count of DRAM interfaces by offering a serial Address/Cmd interface.

It's available in both a standard 96 ball DDR3 package, and a WLCSP. The current OrangeCrab boards should be capable of supporting the 96-ball package with some hw changes.

There is a small errata with the RPC part:

The CS# pin (ball D-3, which is UDM for a DDR3) needs a 50 ohm termination resistor located near the dram and the other end connected to VDDQ
Without the resistor you may get some pretty bad signal integrity / overshoot & undershoot that may possibly cause some problems

Hardware Changes:

• Set VDD_DRAM to 1.5V:
  • R32 <= 100k
• Attach 51R termination between CS# (UDM pin on DDR3) and VDDQ
  • PN: RC0402FR-0751RL

51R suggested placement location

Note: flipped board view. (viewed from back of PCB):

Reported on the 1BitSquared/OrangeCrab discord channel:

Summary

When dfu-util completes it throws an error

Current Behavior

Copying data from PC to DFU device
Download    [=========================] 100%        99405 bytes
Download done.
DFU state(7) = dfuMANIFEST, status(0) = No error condition is present
dfu-util: unable to read DFU status after completion (LIBUSB_ERROR_NO_DEVICE)

Expected Behavior

dfu-util should completes without error and exit cleanly

Not really an issue, but one of the two identical "Zone Outline [GND] on B.Cu" may be removed.

I made the regrettable mistake of overwriting the DFU bootloader by leaving out the "offset" parameter when invoking dfu-util and I am trying to restore it via JTAG with an FT2232H breakout board, and the ecpprog tool. I have the 25F variant, revision 0.2.1.

I tried flashing the bootloader bitstream from here and get the following output:

ecpprog -I B  foboot-v3.0-orangecrab-r0.2-25F.bit  -a
init..
IDCODE: 0x41111043 (LFE5U-25)
ECP5 Status Register: 0x00200100
reset..
flash ID: 0xEF 0x40 0x18
file size: 266307
erase 64kB sector at 0x000000..
erase 64kB sector at 0x010000..
erase 64kB sector at 0x020000..
erase 64kB sector at 0x030000..
erase 64kB sector at 0x040000..
programming..  266307/266307
verify..       266307/266307  VERIFY OK
rebooting ECP5...
Bye.

That seems... good. However after the device resets there is a red breathing pattern on the RGB LED and no DFU device shows up. I am assuming the red LED indicates an error with the bootloader. The result is the same whether I plug in the device with the button pressed or not. I am successfully able to load the blink example in this manner so I think my process for uploading a bitstream to flash is OK. My only other idea is that I am using the wrong bitstream for the hardware I have, but I don't see any on github that might be a closer match.

These two parts are functionally similar, but not drop in replacements.

The bq24232 has a Termination Disable, TD, pin. On the bq24230 this pin is used for Current Limit ILIM.

The schematic should be updated with the correct part number and correct pin labelling.

Is there an STL for the OrangeCrab case that's listed on GroupGets? If so, can you add it to the repository?

See:
https://github.com/gregdavill/OrangeCrab/blob/01f993c3d79f494dfd4e837c9e83c070aad83b74/hardware/orangecrab_r0.1/bom/OrangeCrab.csv#L195

This should be 147k to set the regulator to 1.35v and be consistent with the schematic.

Hello,
I was checking your FPGA-DDR connections and it raised me 2 questions:

1. I can see that there're multiple pads that are used by LiteDRAM as "VCCIO", these pins are connected to P1.35V. The same happens to 2 GND pads. What's really the purpose of these pins? Why are these VCCIO pins connected to K16 D17 K15 K17 B18 C6 specifically? Could the VCCIO (and the GND pins) be connected to other pads of the FPGA?
2. Besides all the differential pairs that need to be connected to a "A" and "B" or a "C" and "D" pins of the FPGA, is there any constraint to consider when choosing which pads of the FPGA will be attributed to each DDR signal?
   Thanks in advance!

To get people up and running quickly some examples should be included.

• Gateware controlled RGB LED pulse/cycle.
• SoC Controlled RGB LED pulse/cycle.
• SoC with DDR3L memory mapped terminal over USB CDC.
• Bootloader

Please find attached zipped .dfu file.

Below is the content of the .pcf file that was used to build the attached zipped .dfu file.

LOCATE COMP "clk48mhz_i" SITE "A9"; IOBUF PORT "clk" IO_TYPE=LVCMOS33; FREQUENCY PORT "clk48mhz" 48 MHZ;

FREQUENCY NET "clk24mhz" 24 MHZ;
FREQUENCY NET "clk96mhz" 96 MHZ;

LOCATE COMP "usr_btn_n" SITE "J17"; IOBUF PORT "usr_btn_n" IO_TYPE=SSTL135_I;

LOCATE COMP "led_red_n" SITE "K4"; IOBUF PORT "led_red_n" IO_TYPE=LVCMOS33;
LOCATE COMP "led_green_n" SITE "M3"; IOBUF PORT "led_green_n" IO_TYPE=LVCMOS33;
LOCATE COMP "led_blue_n" SITE "J3"; IOBUF PORT "led_blue_n" IO_TYPE=LVCMOS33;

LOCATE COMP "usb_d_p" SITE "N1"; IOBUF PORT "usb_d_p" IO_TYPE=LVCMOS33;
LOCATE COMP "usb_d_n" SITE "M2"; IOBUF PORT "usb_d_n" IO_TYPE=LVCMOS33;
LOCATE COMP "usb_pullup" SITE "N2"; IOBUF PORT "usb_d_n" IO_TYPE=LVCMOS33;

LOCATE COMP "sdcard_clk" SITE "K1"; IOBUF PORT "sdcard_clk" IO_TYPE=LVCMOS33;
LOCATE COMP "sdcard_di" SITE "K2"; IOBUF PORT "sdcard_di" IO_TYPE=LVCMOS33;
LOCATE COMP "sdcard_do" SITE "J1"; IOBUF PORT "sdcard_do" IO_TYPE=LVCMOS33;
LOCATE COMP "sdcard_dat1" SITE "K3"; IOBUF PORT "sdcard_dat1" IO_TYPE=LVCMOS33;
LOCATE COMP "sdcard_dat2" SITE "L3"; IOBUF PORT "sdcard_dat2" IO_TYPE=LVCMOS33;
LOCATE COMP "sdcard_cs_n" SITE "M1"; IOBUF PORT "sdcard_cs_n" IO_TYPE=LVCMOS33;

orangecrab02.zip

If folks wish to program the board over JTAG it would be nice to include some openOCD configs that match to the IDCODE of the ECP5's 25F/85F.

I've been trying to locate the DFU source code of the orange crab for a while now, without success. Is there a documented, reproducible build of it somewhere so we can instantiate the base bootloader?

Pros:

• It's the new standard, and as time passes, Type C cables will be more common than micro USB
• It has better mechanical properties than micro USB
• Reversible!

Cons:

• It can confuse users, as the board is wired to make use of at most USB 1.1 (even High Speed is not possible according to the docs). Although not related, people usually assume Type-C => USB 3.0.
• microUSB cables are cheaper (though that might change).

Feather format allows for Type-C connectors to be used instead of micro USB, so it would remain Feather-compatible.

I'm using the examples given on the website to test my FPGA, i use the make dfu command, everything seems to be working, the download is completed, I see a first message which indicates that there is no error, but then the FPGA disconnects (not available when i use dfu-util -l), and I receive this error message...

Has anyone had this problem ?

dfu-util: unable to read DFU status after completion (LIBUSB_ERROR_NO_DEVICE)

There is currently an error in the BOM of the production files for the r0.2.1.
https://github.com/gregdavill/OrangeCrab/blob/main/hardware/orangecrab_r0.2.1/Production/OrangeCrab-bom.csv#L27

R15 and R35 are listed as:

R15 R35 | 2 | 120k | gkl_dipol:R_0201_0603Metric | ~ | RC0201FR-07267KL | ‎Yageo‎ | UNI-ROYAL(Uniroyal Elec) | 0201WMF2673TCE |   |   |  

Note the value is 120K, but has part numbers for a 267K part.

These resistors are used in the DCDC feedback path. The incorrect part placement has the effect of reducing 1.1v and 1.35v rails down to 0.8v and 0.9v respectively.

If I want to try Diamond, to download a bitstream do I need a JTAG? Or can I download the generated bitstream using DFU?

Thanks,
Danilo.

I haven't tested the DDR3 functionality on my board but as a person who does pcb design from time to time i couldn't help but notice a few things

1. UDQS routed with D0-D7 (apparently switched in schematic so nvm)
2. Address lines are randomly split between top and middle layers whilst maintaining the same length, microstrip on top would travel faster though wouldn't it ? so shouldn't the top layer routes be a tad longer considering this and the fact that they don't even need vias, or is this within spec ? (25 mils or 0.6mm ?? i'm sure just a couple vias would account for that)

I'll add more as i learn more about the same. If you have any good resources for ddr3 routing guidelines do share if possible. Thanks!

Issue

Voltage divider resistors were changed to 100k to reduce static power draw.

But this changes the current into the ADC circuit. Because of this different readings of the battery/charger are observed compared to the r0.2 boards.

Suggested action

• Change R32 and R33 to 10k

Do you think this board/FPGA could fit a RISC-V and a memory controller to use the 128MB memory?

any plans for 4.0 or 7.0?

Hello,

I have been trying to compile and upload with the latest Yosys 0.37+34 oss-cad-suite-darwin-x64-20240127.tgz on Mac OS Sonoma 14.2

I can successfully compile and upload the blink verilog examples but not the pll, pwm_rainbow, usb_acm_device examples, which are of interest.

I am adding the result of the make on pll. Any ideas of what is not working?

Thank you

$ make
ecppll -i 48 -o 100 -f pll.v
Pll parameters:
Refclk divisor: 12
Feedback divisor: 25
clkout0 divisor: 6
clkout0 frequency: 100 MHz
VCO frequency: 600
yosys -s "plltest.ys"

 /----------------------------------------------------------------------------\
 |                                                                            |
 |  yosys -- Yosys Open SYnthesis Suite                                       |
 |                                                                            |
 |  Copyright (C) 2012 - 2020  Claire Xenia Wolf <[email protected]>         |
 |                                                                            |
 |  Permission to use, copy, modify, and/or distribute this software for any  |
 |  purpose with or without fee is hereby granted, provided that the above    |
 |  copyright notice and this permission notice appear in all copies.         |
 |                                                                            |
 |  THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES  |
 |  WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF          |
 |  MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR   |
 |  ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES    |
 |  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN     |
 |  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF   |
 |  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.            |
 |                                                                            |
 \----------------------------------------------------------------------------/

 Yosys 0.37+34 (git sha1 80511ced7, x86_64-apple-darwin21.4-clang++ 14.0.0-1ubuntu1.1 -fPIC -Os)


-- Executing script file `plltest.ys' --
ERROR: Can't open script file `plltest.ys' for reading: No such file or directory
make: *** [plltest.json] Error 1

`

I care because I am writing up promo material.

I'm assuming no space because this has no space:

https://github.com/gregdavill/OrangeCrab/blob/master/documentation/hugo-files/content/r0.1/_index.md

Summary

Hardware revision r0.2 didn't have an external resistor on the PROGRAMN pin.
This pin is driven by the FPGA to reset the device into the bootloader.

Observed Behavior

There has been 2-3 reports of users experiencing the the bootloader not loading their programs. Instead the device just sits with the LED on WHITE. Entering the bootloader can be done at anytime by pressing btn0. This behaviour indicates that the device in cycling in/out of the bootloader, since the bootloader only checks the button state once on power-up.

This seems to be related to this pin on some boards the internal resistance isn't strong enough to counteract the weak-pulldown of an I/O pin it's connected to.

Proposed Fix

New hardware

• r0.2.1 features an external pull-up resistor.

Existing r0.2 hardware

• In gateware define the I/O pin connected to the PROGRAMN pin as a HIGH value.

diff --git a/nmigen/blink.py b/nmigen/blink.py
index a966594..cf1803c 100644
--- a/nmigen/blink.py
+++ b/nmigen/blink.py
@@ -23,6 +23,10 @@ class Blink(Elaboratable):
             blue_led.o.eq(self.count[25]),
         ]
 
+        # Ensure FPGA PROGRAMN pin is released.
+        program = platform.request('program')
+        m.d.sync += program.o.eq(0)
+
         return m

Note: in nMigen the program pin defined in the platform file is marked as active low, nMigen internally negates the values we assign to it.

The Flash on r0.1 boards is too small to fit a dual-boot 85F bitstream on without compression. Since compression doesn't give you a guaranteed size it's difficult to say if we can work around this on r0.1

Additionally we are at the maximum Flash density for the package chosen, USON8 2x3, which is 16Mb

By switching the feetprint from USON to WSON or SOIC-8 we can support 128Mb devices, which additionally opens support for devices supporting DDR QSPI, which can be very useful as program space for an SoC.

Current info on the README doesn't specify that the battery connector is for 1S LiPo cell.

I got a pair of boards from https://1bitsquared.com/products/orangecrab and what I received are in fact r0.2.1 boards, which I can't find documentation for. When connecting the boards through USB, they start the default blinking bitstream, but no usb device appears in my kernel logs, even though I'm using a data USB-C cable. I'm not too sure how to proceed without documentation about them to troubleshoot what's going on.

With the switch to https://github.com/YosysHQ/oss-cad-suite-build now, there are some changes that need to be reflected in the getting started guide about windows setup.

The guide also assumes knowledge of git, which shouldn't be required. A paragraph about git should be added.

The ECP5 has two different resets mechanisms.

• Power on Reset
• Device Refresh

Using device refresh we can make use of the ECP5's "multi-boot" feature to load "User gateware" and "Bootloader gateware". We need to investigate if the two different reset mechanisms result in switching between these different gatewares in the same manner.

Ideally I'd like the reset button to reset the User gateware when pressed, and then invoke the Bootloader when held down (2-3s).

If required we can make use of the Microchip ARM processor on board as a "FPGA supervisor".

Hey!
I was checking ECP5's datasheet and on 4.1 Signal Descriptions it says:

PIO A and B are grouped as a pair, and PIO C and D are group as a pair. Each pair
supports true LVDS differential input buffer. Only PIO A and B pair supports true
LVDS differential output buffer.

I wonder why the USB data signals (differential) are not connected to a pin pair (for instance, to PR44C and PR44D)?

Thanks in advance