Lets start with the following library components:
Then Store/retreive files in the wiki:
- FPGA EP1C6 in 240PIN PQFP(GoBox/FPGA)
I like the schematics symbol to have the pins just like the physical device (this makes it easier to prepare for routability etc) you find the pinout in these documents:
http://www.altera.com/literature/hb/cyc/cyc_c52003.pdf its Chapter 3. Cyclone EP1C6 Device Pin Information
- Serial Configuration EEPROM [EPCS1/4] 1 MB for FPGA only up to 4MBit=512k if internal CPU requires Program Memory
you find the pinout Chapter 14. Serial Configuration Devices (EPCS1 & EPC4 Data Sheet http://www.altera.com/literature/hb/cyc/cyc_c51014.pdf
- Memory: (Type: SRAM or SDRAM) Which type will depend largely on availability. Preferably we choose a device that has compatible footprints through 64-256MBit chip with 8 or 16 Bit data Path. This is mostly interesting for the time when we are using a Microcontroller or Soft CPU core. A microcontroller could access the memory through the FPGA, which would act as a sophisticated Memory Controller. If we use an internal CPU we would then consider downloading the program from the serial configuration chip to the plentiful DRAM.
http://www.samsung.com/Products/Semiconductor/DRAM/DDRSDRAM/DDRSDRAMcomponent/128Mbit/K4H281638B/ds_k4h2804(08,16)38b.pdf (contains pinout and Package which are pin compatible for x4 x8 and by 16 data width)
We can also verify that they contain all of the highest address lines like the higher density devices: http://www.samsung.com/Products/Semiconductor/DRAM/DDRSDRAM/DDRSDRAMcomponent/512Mbit/K4H511638D/K4H511638D.htm
Experimenter Analog PWM
With R2 one controls the frequency and with R3 the Duty Cycle. There is still (even if unused) the negative voltage generator on the 555 output pin 3.
It's still missing the FET driver etc...
As seen the circuit is still suffering from some simulation related bugs: Where does the output noise come from?
Initial Circuit for Amplification of the Oxygen Sensor Voltage for connecting an analog instrument and an adjustable voltage offset for changing the Richness of the mix.
Note the problem that the Simulation exits after Microseconds because of a "time interval too small error" has been solved (there is a time step controll in the simulation settings)(Thanks You Tad Johnson for the hint)
What remains is to get the "Non Inverting Voltage Adder" to not amplify just offset!
The 555 part is for generating a negative voltage (~-10V) for allowing the OpAmp to work near zero. This part by itself simulates nice up to 150 mA Load. The Simple voltage follower also kind of has a problem it offsets - honestly the Non-Inverting Adder is my guess (And I am not too fit with Operational Amplifier circuits) I post this hoping for helpful suggestions. Thanks!
GoBox/LogicModule Analog Digital Converters Preliminary Simulations
Simple Ramp and Reset Circuit
Unfinished (needs sensing on limits and center(0))
Marcell: Overengineered?
I just counted the pins for the Processing Unit:
- 1 * 240 pin PQFP FPGA
- 1 * 8 pin SOIC EEPROM
- 1 * 66 pin TSOP RAM
- 1 * 64 pin TQFP uC
For GoBox/TargetSpecifications that could likely be satisfied with an existing GenBoard/VerThree or with small modifications around the power-switchers (eg. for diagnostics) the 64 pin ARM (that has flash, EEPROM and SRAM) would surely be enough with a much smaller pin count FPGA. I would only manufacture multi-trace monster PCBs if really needed.
Tobias: As you know Marcell this is for a small separate Logic Module with connectors to the Power and Sensing Modules, we will stay well within the limits of even the newer free Eagle package.
To agree to put the uC we want your commitment to work with it!
The FPGA has many pins but is reasonably priced and has still a path to double the density in the same package.
I do like a 4 layer PCB (for quality) and we do have sufficient routing manpower/experience level.
In these packages the pin spacing (which defines manufacturing style) is invariable to the less pin, lower density FPGA.
Marcell: I'm not worried about design, a 4 layer auto routes easily. I'm worried about manufacturing and operation. Search for efi332. Efi332 was an engine management system almost as powerful as GenBoard/VerTwo: a bit simpler software-wise and more powerful hardware wise. Only one thing prevented it being a huge success: manufacturability (very similar circuit-topology as you plan, except it was 68332 instead of FPGA).
Let's see what goes wrong usually:
- PCB to PCB connectors (like PCI). These are hell. You want to avoid these on vehicles for any cost. Even on non-moving obstacles, these are the number 1 failure cause (appr. 90%). I just had one such failure in a PC yesterday, but it's really common.
- PCB to cable connectors. Avoid multi-pin connectors. Use serial dataflow from board to board, and only get the signal off board if it's a must (e.g. for the injectors, engine mounted sensors etc...). The 36+18 wire => PCB connector solution is the biggest cost around GenBoard/VerThree.
- Solder-joints: it's hard to avoid these, but less of them makes a better design if otherwise suits the requirements. Many times a serial or a narrow-bus connection onboard (see the SPI, or the 259 solution) is better than a wide-bus (if bandwidth is enough).
- Chips: these are very reliable. If they require small number of outside connections (have internal RAM, EEPROM, flash) than the above does little harm to the design.
Tobias: I know about the connector issues! However we may need the initial flexibility. We are planning to use the 100 mil grid dual row trough-hole headers and cables or direct plug as known from IDE Hard-Disks. This is so we can design parts separately and people also don't have to have all the possible sensor or power modules - only what they need.
Also power or sensing modules don’t necessarily have to be 4 layer...
I like serial interfaces but they cost extra in the chips on the module side (we should make a SerialIOdevice page for those?).
Leaves to emphasize that we will have to 'design in' very capable self-test and diagnosis features!
H2elmut: OK, here is the compromise:
1. The fastest result to get a car run on water is to use the GenBoard, it has everything it needs. So I will continue to support the H2+genboardV3.x version.
2. I agree with Marcell, that the 240pin FPGA and the rest of it is overengineered, plus a 4-layer costs more than twice the price of a 2-layer! (by the way, what is wrong with the quality of 2-layer boards?). In the end the FPGA is a nice to have but expensive platform to start with...
But OK I will design this board for you Tobias, so that you can get rolling... hopefully you have some customers that are later willing to pay a higher price for this GoBox/FPGA.
3. The power and sensing module can be designed to be connected to the H2+genboard as well as to the GoBox/FPGA.
I can commit to the H2+genboard and to the GoBox/FPGA and/or GoBox/CPU and peripherals all in parallel, no problem.
I hope this challenge will encourage all parties to get rolling faster... and HEY! which one will be first driving through the goal on tapwater ?!?
Cheers, H2elmut
Tobias: I agree with you - However Its not the price that will sell the GoBox Concept!
Have you seen the latest GenBoard/UnderDevelopment/VerThree - its a work of art! Even if its a monster :) of cramped complexity; it does make my electronics heart beat higher.
In comparison the GoBox Modules may end up to be very simple!
The wind in our sails is the enthusiasm that DIY Car hobbyists and professionals will gain, when they travel so much further for the same fuel. There are already the WaterInjection users or those that are planning to implement it, that can speak prove about it!
I have the intuition that there will be at least two 'famous' FPGA developers that will want some Open Source GoBox PCB sets those are Martin the developer of the Java Optimized Processor and Doru the developer of pAVR core.
?what is wrong with the quality of 2-layer boards? : Your right it can be ok - Modern FPGA have slew rate control - if not its that old problem that the return current for optimal impedance likes to travel in the Magnetic field of the forward current that is only possible in Multilayer Boards - if the return current flows a seperate path one can theoretically get loops producing induced false signals when a number of lines switch at the same time and at high speed (very hard to debug).