• Please review our updated Terms and Rules here

SCSI-1/2 USB and/or SD card converter

E

eeguru

Veteran Member
Joined
Mar 14, 2011
Messages
1,618
Location
Atlanta, GA, USA
lynchaj said:
Show me the hardware.
Click to expand...

Since you asked. See board layouts on pages 2-5.

PTH Design

Besides being fully PTH, its a about 3.5 times smaller allowing it to fit into tighter inner case spaces, has 4x the ROM space, orders of magnitude faster transfer speeds (would peg SCSI-1), uses a modern interface - USB instead of PATA, supports optional direct PC emulation of the SCSI drive, about 1/5 the parts cost, and can be programmed using the same tools as the current S2I design (EEPROM programmer) as well as supporting in-circuit programming and debug.

No limits design

Using SMT much more is possible. Besides the ultra small board size with no over-hanging components on connectors, it could be plugged directly into a SCSI host controller socket with a female downward facing header. The header is also full reversible with auto-detection so that the board can be oriented either way. Could keep up with 20MHz single ended Ultra(narrow)-SCSI. And it could be mass produced on a kick start for under $50.

Just a couple options.

lynchaj said:
Hi

That's great! I look forward to seeing your board.

Now would you please start your own thread?
Click to expand...

Deal.
 
Getting a few PMs, so I'll answer questions here.

I have a SiLabs eval board on it's way. I'm a bit concerned whether anyone has worked out a gdb/Linux solution yet either using the SiLabs debug cable or something like ST-Link. If gdb isn't a problem, I'd much prefer just starting with that design. Even if all the PLD had in it was signal routing, a few latches and interrupt on change, bit banging everything else at least through an investigation phase would certainly be doable with an 80 MHz M3. From there, the only thing I ever expect the PLD logic to do is track the bus states and perform a simple DMA transfer engine for clocking in/out SCSI bus messages. Either in to/out of a bi-directional FIFO with either the SD card logic or a WB interface to RAM and the M3 on the other end. There is only 2KB block RAM on the lowest device in the family so it might be a challenge.

I'm used to doing designs with ST's STM32 series. But the SiLabs part made interfacing to the PLD and internal Wishbone peripherals stupid easy and very fast. And it's cheaper to add an external hard core than a larger FPGA and internal soft core.

Even if the SiLabs development environment isn't great, the default IDE and ICP/D cable should be fine to do development on. The only real challenge with the PLD design is unbricking if there is a power loss during reflashing of it. The MCU can normally reflash it over the parallel bus interface while it's running to upgrade HDL designs.

If PTH is a design requirement that's worth supporting, the Microchip approach is also worthwhile. Because of the 53C80, it's only going to be SCSI-1. But there should be no problem hitting the saturation speed of up to ~1.2 MB/s if the host supports it. And USB sticks and home assembly are very attractive also.

With more CPU and ROM, multiple SCSI IDs and/or LUNs could be emulated with the same device. Could be done either with multiple partitions or even files on a FAT32 partition.

Looking for thoughts on PTH. It certainly would be quicker to get working boards in working hands.
 
Al Kossow said:
I don't understand the three row connector for SCSI in the PCB layout.
Click to expand...

The idea is that you would put a female header on the underside of the board and plug it straight into the 50 pin male SCSI controller PCB connector on, for example, a MAC SE. The thing is, the MAC SE (eg) SCSI connector is located close to an edge of the MB. So depending on which way the connector plugged in (tab orientation), my little wing board above may be facing the wrong way and not have enough room to fit - ie. would virtually extend out the side of the case. Now that won't do. So what I'm proposing is a three row pin layout that allows you to orient the 'tab' on the SCSI connector either pointing in or pointing out so that the orientation of the wing board is reversible. The catch is you must solder it in to either the top two rows (tab outward) or bottom two rows (tab inward) based on the machine you are using it in. Since one row in SCSI is mostly grounds and the other row mostly signals and everything else symmetric, this works. And it allows the most flexibility in supporting the greatest number of machines that have connectors next to the inner wall of a case tab facing in or tab facing out. And the SCSI standard builds in a routing feature - the ATN signal skipping a pin - that would allow the PLD to detect on which side the data signals verses the control signals are based on seeing the pattern 0101 or 1010 on the two most inner SCSI signal traces and auto-route accordingly.

The idea is was to design a DoM (Disk on a Module) - similar to this one for PATA. Which is a simple wing board that historically plugs into an IDE PATA slot or SATA slot and contains a high capacity SMT flash. Same concept here except since managed NAND generally only comes in BGA packages and leaded un-managed NAND needs a more complicated wear leveling controller, a SD card running in SDIO mode for speed (~25 MB/s) becomes a good substitute.
 
eeguru said:
The idea is that you would put a female header on the underside
Click to expand...

ah..

Were you going to organize a whole package with the tool chains for the microcontroller and pld?
I have a couple of projects of this complexity I'm working on now, and the problem isn't the hardware, but
getting all of the software pieces pulled together for development. I've ended up with a whole pile of code
from various places to do parts of the problem, but it takes a fair bit of work to get it all organized and
playing together. In my case, it is for a Stellaris uC and Cyclone II
 
Yes everything will be contained in a public svn including a Diamond project. However it's pretty straight forward to pull in a raw Verilog source stack into a new Diamond project and synthesis for the standard targets (area, prop delay, etc). The PLD logic will be kept very simple to just bus state tracking and simple data movement loops. If someone wanted to work on that, they could since it could be reprogrammed through the MCU. But I expect I'll need to do a fair bit of leg work to get people boot strapped. Lattice offers a free node locked license similar to Xilinx and Altera. And Diamond is also Eclipse based and tightly integrated.

For the ARM side, straight gcc and make. No SiLabs peripherals are used besides one UART for console printfs. Everything else is in the PLD - PWM for activity/error LEDs, XO2 hardened SPI at first, modified Opencores SDIO controller eventually, and SCSI logic. Any ARM gcc tool chain will work - the one that comes with SiLabs Precision32, Code Sourcery Lite, etc.

Timeline wise, hoping to get feedback this week and sent out one of the two boards next weekend for prototype orders. Should have them in development helper hands towards beginning of Feb. Though I suppose I could do both in parallel if there were people interested in building up the PIC32 board and writing code (would be a PCB only project).

The problem with any of these projects is finding people to help with the software development side. I'm hoping standard 32-bit C over Z80 assembly helps with that - both initially and in long term maintenance.
 
Last edited:
Same SCSI termination rules apply. However the DoM is intended to be plugged directly into the SCSI host controller header. So it will be close to active termination and term power. If there are devices connected on a secondary connector, then they need termination at the far end of the cable.

The AUX pin is there so that if a host doesn't provide termination power, a jumper wire & pin can be run over to somewhere else on the MB where +5 can be found. The MCU and PLD should pull no more than 25mA during active operation and less than 2 mA during idle. The SD card can pull up to 100 mA, however most use cases will be the DoM plugged directly into a host controller, no other devices on the chain, and no need for a long cable - thus no need for a second termination set. So there should be plenty of room on the termination power rail to power everything just fine.
 
Hi eeguru!

If i understander right your design uses a USB stick/drive instead of pata? That would be awesome!
Do you hace an estimate for getting this project ready? This looks so great that i guess i can wait for it! :D

Thanks

Jose
 
The PIC32 solution would be USB. There definitely is merit in going that route rather than the more compact DoM. A PTH design would be more sustainable by a wider array of people after the first production run. However I'm really not crazy about the use of a chip that's been out of production for a while (Z53C80).

I have very little experience with PIC32 so if someone who does could proof my design above, it would be much appreciated. I've since put some isolation between PGEC/PGED (D1/D0) and MCLR around the MCU/ICSP and the rest of the board for programming.
 
Last edited:
I think the solution shoud be separated from storage so media can be replaced in case it fails. That's why i thought the pic32 and USB would be great.
But if there is a way to get a solution in between with modern and faster components (DoM with USB/SD for example) it would be even better.
Anyway, electronics is still like chinese for me... all i know is that i really need this SCSI card converter...
Hope this project get its way to a final product.
Thanks.
Jose
 
I finally got boards in and built up, however both have infant mortality in that I can't get either board to connect with in circuit debugging.

On the PIC based board, I'm using a PICKit 3. I've even modified the board to remove the MCP130 and replace it with more traditional 2K pull up and .1uF parallel cap to ground. I've also moved the diode and replaced it with a more traditional 470 ohm resistor. Yet I still cannot get the PICKit 3 to connected to the target. If anyone has any suggestions, I'd appreciate them.

On SiLabs M3, same situation but less to change to make it work. I can however go forward with testing the electrical interface. I'm travelling nearly the entire month of February for work, so progress may be slow.
 
I'm finding these projects very interesting myself, as someone who still has a Mac Classic (the 68000 version, even) lying around. It's got a 1.2 GB Quantum in it now, but that thing is pushing 20 and probably won't last that much longer.

eeguru said:
The PIC32 solution would be USB. There definitely is merit in going that route rather than the more compact DoM. A PTH design would be more sustainable by a wider array of people after the first production run. However I'm really not crazy about the use of a chip that's been out of production for a while (Z53C80).

I have very little experience with PIC32 so if someone who does could proof my design above, it would be much appreciated. I've since put some isolation between PGEC/PGED (D1/D0) and MCLR around the MCU/ICSP and the rest of the board for programming.
Click to expand...

I notice that the SCSI target adapter and the SD I/O are in the FPGA on the DoM design. I'm wondering if something similar could be done with the PIC32 design; use a smaller FPGA or CPLD to emulate a 53C80, then stick it on a PGA or DIP-40 adapter board. (This would also broaden the horizon a bit, since it's an FPGA and could even emulate a 53C9x if someone felt like it.)
 
You must log in or register to reply here.
Back
Top