Skip to main content ↑ ↓
Topic: Parts list (rough design, options) (Read 72418 times) previous topic - next topic

Re: Parts list (rough design, options)

Reply #45 –
An expansion board is a good solution. My idea to move some of the signals to the buffered pins in a custom synthesis would only work for input pins since there isn't per bit pin direction control.
Got a question? Please ask in the forum for the fastest answers.

Re: Parts list (rough design, options)

Reply #46 –
I uploaded a custom library for the pic 18f24j50 to the SVN. I was going to add the buffer and try to modify the S3 footprint but I didn't see the library at your site or in the S3 cocoon SVN/downloads.
Got a question? Please ask in the forum for the fastest answers.

Re: Parts list (rough design, options)

Reply #47 –
[quote microchip]
Self programming Flash supports 10k erase/write cycles
[/quote]

I dont know much about this project other than it looks good.
but is the write cycle of the 18f24j50 series going to be an issue?

Re: Parts list (rough design, options)

Reply #48 –
I just exported the library and committed it into svn.

Jack.

Re: Parts list (rough design, options)

Reply #49 –
I know I'm a bit late, but if you're using the Spartan-3E 250 I'm sure you can implement everything you need in the FPGA.

http://www.xilinx.com/products/ipcenter ... DEVICE.htm
http://www.xilinx.com/products/ipcenter/CIPPICL-X.htm

Re: Parts list (rough design, options)

Reply #50 –
audihacked, thnx for the links ... I think the CIPPICL-X soft-IP has been around for some time but I couldn't find any details on the implementation nor on the license model/cost ... it may not be free ???

This is all I found about the CIPPICL-X/CIPPIC softcore: Cheetah Hi-Tech, Inc. - Products and 2K word instruction ROM - even 8K word instruction ROM for the CIPPIC implementation - may not be enough code space for the project

I think Ian and Jack decided to go for a "hard MCU" for various reasons like

- use Jacks proven LA implementation for the Spartan-3E 250 without any/many changes
- keep the design open for different implementations/different MCUs
- allow for as much as possible of the FPGAs RAM to be used as a capture buffer ...

... the resources of the XC3S250E are kind of limited and the XC3S500E -  the "largest" Spartan-3E available in a 100-VQFP package - would cost about US$ 7 extra ... eating up US$ 20 of a targeted retail price of US$ 40 max.

Re: Parts list (rough design, options)

Reply #51 –
I made these updates to the PCB and saved it to SVN:

Removed the board outline and Butterfly I/O pins
Added simple 6 pin JTAG header
Changed caps to 0805
Updated CCT to use the new 18FxxJ footprint
Updated my half to be consistent with Jacks power naming (3v3, 2v5, 1v2).
Named connections for bigger rom, ROM connections on programming header
Squished the parts together a bit

Here's what I need to finish a draft:
1. Jack mentioned that the ROM footprint was a little small. I added an alternate to the PCB. Is this the correct size? Which one will work?
2. A footprint for the 16bit buffer IC. If you add a copy of the buffer wing to SVN I'll copy it from there.
3. Where should I connect the 4 pin SPI/UART connection + control pins (how many? 2?)? These will be 3.3volt signals, as will the shared PIC and FPGA connection to the ROM. I imagine this will share bank2 pins?
4. Which pins will we use for the 32 I/O pins?
5. Which/how many additional signals do we want at the pin header for clock in, etc?
Got a question? Please ask in the forum for the fastest answers.

Re: Parts list (rough design, options)

Reply #52 –
Sorry, hit post instead of preview. Here's a PNG of the PCB as it is now. I changed the name of the PCB to a, there was a good reason but I forget now.
Got a question? Please ask in the forum for the fastest answers.

Re: Parts list (rough design, options)

Reply #53 –
[quote author="ian"]
Sorry, hit post instead of preview. Here's a PNG of the PCB as it is now. I changed the name of the PCB to a, there was a good reason but I forget now.
[/quote]
Looks nice. Are this 16Bit  Connectors? If yes, you may be a little short on ground and power Pins. Another  nice addition addition would be an
I2C or SPI bus on the probe connector. Then one could build a software controlled power supply for the buffer board. This way you could change
the I/O voltage of the translator chip from the analyzer software. But you could always do this with a jumper on the buffer board or get the voltage
from the target board.

If you are still using the AT45DB021D there are two variants of the chip, one 0.150" wide and the other 0.209 wide. One could make a footprint
with longer [s:]pins[/s:] pads that  would accommodate both.
 
Klaus Leiss

Re: Parts list (rough design, options)

Reply #54 –
Looks great!

I checked the Buffer design into SVN, it is a board only design but should be good enough for getting the footprint from. What do you think about having different numbering schemes printed on the PCB like on the checked in buffer design? Changing the FPGA bitstream allows the connectors to be renumbered and might be useful.




1. Jack mentioned that the ROM footprint was a little small. I added an alternate to the PCB. Is this the correct size? Which one will work?
    It looks like it is going to be correct, once we get the Buffer footprint on the board I will do a 1to1 printout and verify the Atmel Flash and Buffer footprints with the actual parts.

2. A footprint for the 16bit buffer IC. If you add a copy of the buffer wing to SVN I'll copy it from there.
   Checked into SVN now.

3. Where should I connect the 4 pin SPI/UART connection + control pins (how many? 2?)? These will be 3.3volt signals, as will the shared PIC and FPGA connection to the ROM. I imagine this will share bank2 pins?
   I just looked at the datasheet and it looks like the AT45DB041D (2.5V Version) part accepts 2.5V to 3.6V for VCC. (http://www.atmel.com/dyn/resources/prod_documents/doc3595.pdf) The schematic should already have them connected to the correct locations on the FPGA. One change I think we can make that might make things easier is to just connect the /CS pin to ground so it is always active. It is currently connected to the FPGA and I noticed that the SPI header does not have a pin for /CS. So if we don't create another pin on the header or make the SPI Flash always active then we won't be able to program it over the SPI header.

4. Which pins will we use for the 32 I/O pins?
   This is the part that gets tricky, we can use any available IO pins (I usually avoid IP, or input only, pins). If we are going to accomplish speeds over 50Mhz though we need to keep the traces as short as possible and route them over an unbroken ground plane. So I usually save determining which pins for the very last step. If we get the design to where we want it we can then make a copy of the board file which will break the forward/back annotation. We can then easily route and reroute the signals to figure out the best configuration. We then update the schematic with what we did on the temporary board file. It is a pain and tedious but its the most effective way I have found, Eagle doesn't have very good support for the back annotation needed in FPGA designs where the pins are really flexible.

5. Which/how many additional signals do we want at the pin header for clock in, etc?
   TBD

I'm going to spend a little time trying to validate the SPI design on some hardware I have here. Once that is done then I will start updating the EAGLE design. I want to get the SPI validation out of the way before we get real serious with routing the design.

Jack.

Re: Parts list (rough design, options)

Reply #55 –
Quote
3....One change I think we can make that might make things easier is to just connect the /CS pin to ground so it is always active. It is currently connected to the FPGA and I noticed that the SPI header does not have a pin for /CS. So if we don't create another pin on the header or make the SPI Flash always active then we won't be able to program it over the SPI header.

The SPI headers (you're talking about the header labeled ROM ISP?) I used are for AVR ISP, CS is just called RESET. I used that header so the pinout would be consistent with common AVR programmers (I think many will program ROM chips through AVRDude, etc). This isn't the best idea because the STK500, etc, work at 5volts which is way beyond specs. We can (should) change it so there's no motivation to even try :)

I've only worked with EEPROMs like the 25AAxxxx, but I thought CS was a required signal. I've been studying the ROM chip datasheet in case I have to make custom programming software for the PIC, I'll check it out.

The reason I mentioned 3.3volts is because the PIC will program the ROM at 3.3volts, so I wanted to make sure that the bank connected to the ROM chip can tolerate it.
Got a question? Please ask in the forum for the fastest answers.

Re: Parts list (rough design, options)

Reply #56 –
Good news,

I just finished validating the SPI Flash configuration portion of the design. I just succeeded in flashing a bitstream to the SPI flash on a S3E Cocoon 2.0 board that I've been working on. The board starts up and loads the bitstream in the amount of time it takes for the USB ports to register. So I feel confident now that the SPI Flash configuration portion of the Sump Pump design should work well.

Now its time to dive into the EAGLE design part of this project. Hopefully we will have a design ready in the next week or so, this is starting to get exciting!

Jack.

Re: Parts list (rough design, options)

Reply #57 –
If you could add the Wing connector that we discussed earlier, first, that would really help me to be able to route the rest of the PCB.
Got a question? Please ask in the forum for the fastest answers.

Re: Parts list (rough design, options)

Reply #58 –
Ok, that will be my first task.

After a chat with Ian we feel that the best way to enable all of the ideas that have been posted is to include an 8 Bit buffer on the board and a 16 Bit Wing that can accommodate standardized peripherals/addons such as buffered signals, ADC's, Oscope probes etc.