Modular FPGA Miner Hardware Design Development - page 7.

Olaf.Mandel

member

Activity: 70

Merit: 10

Quote from: TheSeven on August 01, 2011, 11:27:06 AM

Quote from: Olaf.Mandel on July 31, 2011, 11:12:43 AM

Refinements on PSU section:
- Added 3.3V -> 2.5V PSU

[...]
So you want to feed the FPGA's 2.5V rail through the MSP's built-in LDO? Doesn't sound good Undecided

Of course not. There are two 2.5V supplies in the PSU design:

VCC: Fed by the 3.3V LDO in the MSP430. Powers the MSP430 and nothing else.

VCCIO: Fed by the +12V connector. Powers the VCCio rail of both FPGAs.

TheSeven

hero member

Activity: 504

Merit: 500

FPGA Mining LLC

Quote from: Olaf.Mandel on July 31, 2011, 11:12:43 AM

Refinements on PSU section:
- Added 3.3V -> 2.5V PSU

Quote from: Olaf.Mandel on July 31, 2011, 03:48:58 PM

I currently placed two MCU supply voltages on the DIMM connector: +5V which is connected to the USB 5V, and +3V3, which is connected to the output of the LDO inside the MSP430 (this LDO is fed by the +5V). I wanted to have the backplane supply 5V only if it used the USB connection and supply 3.3V otherwise. But there should be a different way to detect the presence of the USB host. So any concerns about removing the +3V3 signal from the DIMM?

So you want to feed the FPGA's 2.5V rail through the MSP's built-in LDO? Doesn't sound good Undecided

O_Shovah

sr. member

Activity: 410

Merit: 252

Watercooling the world of mining

Quote from: Olaf.Mandel on July 31, 2011, 04:33:13 PM

Quote from: O_Shovah on July 31, 2011, 04:29:42 PM

[...]
I m sorry for making you clean up my mistakes. I hope i produce more advance than work. Sad

Not much work. I said it to make you learn the "eagle way" of schematic entry. I guess transitioning from a different program is tough.

Thank you

In Altium its impossible to lay a line to a pin, without either connecting it automatically or getting a dialogue wich ask wich network the whole setup should be assigned to.

Olaf.Mandel

member

Activity: 70

Merit: 10

Quote from: O_Shovah on July 31, 2011, 04:29:42 PM

[...]
I m sorry for making you clean up my mistakes. I hope i produce more advance than work. Sad

Not much work. I said it to make you learn the "eagle way" of schematic entry. I guess transitioning from a different program is tough.

O_Shovah

sr. member

Activity: 410

Merit: 252

Watercooling the world of mining

Quote from: Olaf.Mandel on July 31, 2011, 03:48:58 PM

[...]
@O_Shovah: You still have some trouble with using eagle. Some of your wires were not connected to the pins they touched. The order is important here: either place a part on top of existing wires or draw a wire to touch a pin. Moving a wire to touch a pin does not work. Also, you cannot change the signal carried by a wire by placing a suitable label close to it. You need to use the NAME command. It is usually a good idea to first use the label command to actually get the name displayed and then use the NAME command to change it and see the change in the label.
[...]

I m sorry for making you clean up my mistakes. I hope i produce more advance than work. Sad

Quote from: Olaf.Mandel on July 31, 2011, 04:17:05 PM

I just read through the MSP430 docu and found two things:

Good news: multiple SSEL signals are no problem. The STE signals provided by the serial engine are different from the SSEL signals. They are to facilitate multiple masters on one bus, so we don't need them. This means we can set UCMODEx=00 (3-wire mode) in both UCA1CTL0 and UCB1CTL0.

Bad news: the way the two serial engines are multiplexed onto the output pins, it is impossible to configure one engine to 4-wire mode and use the second engine at the same time. We don't need to to that, but this raises the question if two concurrent 3-wire SPI engines on the same port are even possible at all. Can anyone who knows their MSP430 forward and backward answer this? Alternatively we could use a 64-pin package (the 5510IRGC).

So that verifiys my first impression.
I also considered the 64 pin package. I doesn't need much more space and would provide plenty of additional pins with the second block for SPI in the 5510.
And we should also consider the case of using more than 2 FPGA's.

Olaf.Mandel

member

Activity: 70

Merit: 10

I just read through the MSP430 docu and found two things:

Good news: multiple SSEL signals are no problem. The STE signals provided by the serial engine are different from the SSEL signals. They are to facilitate multiple masters on one bus, so we don't need them. This means we can set UCMODEx=00 (3-wire mode) in both UCA1CTL0 and UCB1CTL0.

Bad news: the way the two serial engines are multiplexed onto the output pins, it is impossible to configure one engine to 4-wire mode and use the second engine at the same time. We don't need to to that, but this raises the question if two concurrent 3-wire SPI engines on the same port are even possible at all. Can anyone who knows their MSP430 forward and backward answer this? Alternatively we could use a 64-pin package (the 5510IRGC).

Olaf.Mandel

member

Activity: 70

Merit: 10

I uploaded a new version of the MCU design (minimal changes) to github and dropbox. Commit logs:

Changed names of SPI signals in DIMM
Copied in MCU design by O_Shovah
Repaired MCU design: There were several defective wires: not attached to pins and wrong names

@O_Shovah: You still have some trouble with using eagle. Some of your wires were not connected to the pins they touched. The order is important here: either place a part on top of existing wires or draw a wire to touch a pin. Moving a wire to touch a pin does not work. Also, you cannot change the signal carried by a wire by placing a suitable label close to it. You need to use the NAME command. It is usually a good idea to first use the label command to actually get the name displayed and then use the NAME command to change it and see the change in the label.

I currently placed two MCU supply voltages on the DIMM connector: +5V which is connected to the USB 5V, and +3V3, which is connected to the output of the LDO inside the MSP430 (this LDO is fed by the +5V). I wanted to have the backplane supply 5V only if it used the USB connection and supply 3.3V otherwise. But there should be a different way to detect the presence of the USB host. So any concerns about removing the +3V3 signal from the DIMM?

Olaf.Mandel

member

Activity: 70

Merit: 10

Quote from: O_Shovah on July 31, 2011, 12:14:27 PM

[...]
Im still in route for the second SSEL pin to the FPGA's and The clock in/output
EDIT

Please correct me if im wrong.
But it seems as we dont have a second SSEL pin here for the FPGA's and in addition we need a MSP modell with two A and B USCi blocks so we may use all signals on correct pins ?
Or are we supposed to use the Pins 35 and 36 for this purpose. ?

I just uploaded a DIMM connector, and of course I got the _D to _M wrong. I will upload a corrected version soon. I think one USCI_A and one USCI_B block should suffice. My only uncertainty: how to generate two SSEL signals from one block? Could be that those two pins can be used, but I don't know for sure.

And I made a mistake in a previous post: we need to preserve the +5V symbol on the USB pin 1: this needs to route to the DIMM connector also, so that the MCU can detect a USB connection. Can you restore it?

And the SSEL_D signal can be routed in a bus (the blue lines) the correct name in this case is SSEL_D[0..1] .

O_Shovah

sr. member

Activity: 410

Merit: 252

Watercooling the world of mining

I uploaded a merged variant of your and my MCU parts.

I used the following line syntax:

eg SSEL_D1; SSEL is the slave select line "D" stands for : The line is located on the DIMM so in this case the MCU is Master "1" is the number of the FPGA this line is headed for

And SSEL_M; SSEL is the slave select line "M" stands for : The line is headed to the Motherboard so in this case the MCU is Slave

Im still in route for the second SSEL pin to the FPGA's and The clock in/output
EDIT

Please correct me if im wrong.
But it seems as we dont have a second SSEL pin here for the FPGA's and in addition we need a MSP modell with two A and B USCi blocks so we may use all signals on correct pins ?
Or are we supposed to use the Pins 35 and 36 for this purpose. ?

Olaf.Mandel

member

Activity: 70

Merit: 10

Quote from: O_Shovah on July 31, 2011, 10:41:08 AM

Ok so i'll start wire it this way.
I should be finished soon.
I will use .._Hn for host and ..._Sn for slave parts. So n stands for the devicenumber.

I don't quite get it: n stands for what, exactly? There is only three chips here and there is only two busses: host and FPGAs. Actually, for the two FPGAs, the signal names already encode the number: SSEL0 or SSEL1.

Olaf.Mandel

member

Activity: 70

Merit: 10

I uploaded a new version of the PSU design and a new MCU design (minimal changes) to github and dropbox. Commit logs:

Fixed name of MSP430 package: PT48 -> RGZ48
Updated library after learning about technologies:
- Started using the ? and * keywords in device names, changed several parts
- Added the PT48 package to the MSP430F55*I part, added attributes
- This causes an incompatible name change in the MSP430F55XX device: use the replace command
- Added the LM3671 device
Refinements on PSU section:
- Added 3.3V -> 2.5V PSU
- Changed all devices to default libraries
- This specifically includes changes to the CPOL parts: they were oriented the wrong way around
Small changes to MCU:
- Changed name of VUSB to +3V3 (by changing the supply symbol)
- Removed +5V name (by deleting the supply symbol)
- Named the two USB signals DM and DP
- Added two V<-> symbols and routed them to DM and DP

@Li_gangyi: Can you verify the capacitors in the PSU? I changed them to something in the default rcl library (your parts were from a non-standard lib). But this turned the CPOL elements around. Please make sure you agree that the negative pin is marked on your parts.

@O_Shovah: You can update you local copy of the MCU.sch that you worked on by doing the following steps (maybe first open my schematic for a quick peek):

Get the new project.lbr and update the schematic
REPLACE the MCU device with the MSP430F5507IRGZ
DELETE the VUSB symbol
ADD +3V3@supply1 in its place
DELETE the +5V symbol and the stub of wire connecting to it
NAME the nets going to the two ESD diodes DM and DP
ADD two V<-> symbols at these coordinates: (0.8 6.7) and (0.8 6.6). Both are rotated by 180 degrees
Change the VALUE of each symbol: the upper one to DM, the lower one to DP
Route a NET to the symbols, starting at the two ESD diodes

O_Shovah

sr. member

Activity: 410

Merit: 252

Watercooling the world of mining

Ok so i'll start wire it this way.
I should be finished soon.
~~I will use .._Hn for host and ..._Sn for slave parts. So n stands for the devicenumber.~~

Olaf.Mandel

member

Activity: 70

Merit: 10

Quote from: O_Shovah on July 31, 2011, 08:20:00 AM

[...]
I've got a very basic question regarding the SPI net.

One part of our SPI BUS, is between the wo FPGA's and the MSP 430 with the MSP acting as a Master towards the FPGA's wich are independent Slaves.
The other part is the MSP acting as a independent SPI slave towards another master located on the motherboard (another MSP 430 or an ARM cpu).

So the MSP on the DIMM is both slave an Master in SPI eg using USCI_A as master part and USCI_B as slave part.

So it can either recieve work and instructions via SPI from the motherboard or in standalone operation via USB.

Am i having the correct idea of the Network or am i running in a totally wrong direction.
I would like to know this so i dont start building nonsens.

This sounds exactly right! One bus to the FPGAs using SCLK, MOSI, MISO, SSEL0 and SSEL1, and another bus using some other signals. Can we decide on the signal names now? Maybe H_SCLK, H_MOSI, H_MISO, H_SSEL (where H_ stands for "host") or MCU_*, or even *_2 or something. Which are you going to use? Don't forget that MOSI and MISO have different meaning between the two busses: input and output are swapped.

O_Shovah

sr. member

Activity: 410

Merit: 252

Watercooling the world of mining

Quote from: Olaf.Mandel on July 31, 2011, 08:07:13 AM

Quote from: O_Shovah on July 31, 2011, 07:19:23 AM

Ok so thats ruled out so far.

I just added the TDI TDO TCK and TMS net.I uploaded the modified schematic into my folder.Just a little mod.

I'm currently reading about the TCK and TDIO for the SPI BUS ( Pin 48 & 47) but im still not sure about the additional requirements.

I think you can leave RST/NMI and TEST unconnected, because you are not actually using the JTAG pins to debug the MSP430. You connected them to the FPGA, so they are used as normal GPIO pins. In that case, nothing should be needed for the RST and TEST pins (maybe an RC-element for the RESET as a brownout detection?). You do realise that in this configuration, you could have used any of the other port pins for the JTAG connection, right?

Ok so we will just leave them floating.

I've got a very basic question regarding the SPI net.

One part of our SPI BUS, is between the wo FPGA's and the MSP 430 with the MSP acting as a Master towards the FPGA's wich are independent Slaves.
The other part is the MSP acting as a independent SPI slave towards another master located on the motherboard (another MSP 430 or an ARM cpu).

So the MSP on the DIMM is both slave an Master in SPI eg using USCI_A as master part and USCI_B as slave part.

So it can either recieve work and instructions via SPI from the motherboard or in standalone operation via USB.

Am i having the correct idea of the Network or am i running in a totally wrong direction.
I would like to know this so i dont start building nonsens.

Olaf.Mandel

member

Activity: 70

Merit: 10

Quote from: O_Shovah on July 31, 2011, 07:19:23 AM

Ok so thats ruled out so far.

I just added the TDI TDO TCK and TMS net.I uploaded the modified schematic into my folder.Just a little mod.

I'm currently reading about the TCK and TDIO for the SPI BUS ( Pin 48 & 47) but im still not sure about the additional requirements.

I think you can leave RST/NMI and TEST unconnected, because you are not actually using the JTAG pins to debug the MSP430. You connected them to the FPGA, so they are used as normal GPIO pins. In that case, nothing should be needed for the RST and TEST pins (maybe an RC-element for the RESET as a brownout detection?). You do realise that in this configuration, you could have used any of the other port pins for the JTAG connection, right?

O_Shovah

sr. member

Activity: 410

Merit: 252

Watercooling the world of mining

Ok so thats ruled out so far.

I just added the TDI TDO TCK and TMS net.I uploaded the modified schematic into my folder.Just a little mod.

I'm currently reading about the TCK and TDIO for the SPI BUS ( Pin 48 & 47) but im still not sure about the additional requirements.

Olaf.Mandel

member

Activity: 70

Merit: 10

Quote from: O_Shovah on July 31, 2011, 06:28:50 AM

Quote from: Olaf.Mandel on July 31, 2011, 12:49:49 AM

Quote from: O_Shovah on July 30, 2011, 05:22:13 PM

[...]
Did i miss something ? In the version i uploaded the MSP 430 f 5507 has a RGZ package i thought we agreed to use this one. ?

Sorry, my mistake. I started working on the file and decided to copy the device into the project.lbr library. I only looked after doing the copy from the downloaded TI library.
[...]

Seems we had a little missunderstanding here Wink

I thougt you claimed we should use the RGZ package but i was wrong.

Actually, that is exactly what I want: the PT package is only available for the 5504, 5508, 5509 and 5510. The RGZ package is available for all 5500 through to 5510. So I actually had it right in my first post. But I can see where your confusion comes from: the package in my schematic is named PT48. Actually, I forgot to rename it! If you look at the package or read its description, it should be named RGZ48. I will change that in my version of the package.

Quote from: O_Shovah on July 31, 2011, 06:28:50 AM

So now we gonna go on with you schematic.

I will add the lines for clk and FPGA IO to the schmatic afther lunch.

You will add the lines? Perfect. But which clock lines? The 25MHz CLK signal is already connected. Or do you mean the TCK and SCLK lines?

What is currently completely missing are the connections to the DIMM bus and the 3.3V -> 2.5V converter. I will start adding the power supply to the PSU design today. If there is time, I will also start making a design for the connections to the DIMM bus.

O_Shovah

sr. member

Activity: 410

Merit: 252

Watercooling the world of mining

Quote from: Olaf.Mandel on July 31, 2011, 12:49:49 AM

Quote from: O_Shovah on July 30, 2011, 05:22:13 PM

[...]
Ok, what else needs to be done to the MSP section?
I'll have a look to change the package tomorrow.
EDIT
Did i miss something ? In the version i uploaded the MSP 430 f 5507 has a RGZ package i thought we agreed to use this one. ?

Sorry, my mistake. I started working on the file and decided to copy the device into the project.lbr library. I only looked after doing the copy from the downloaded TI library.

You saw my previous comments on the MCU?

Seems we had a little missunderstanding here Wink

I thougt you claimed we should use the RGZ package but i was wrong.

So now we gonna go on with you schematic.

I will add the lines for clk and FPGA IO to the schmatic afther lunch.

Olaf.Mandel

member

Activity: 70

Merit: 10

I uploaded a new version of the FPGA design (minor changes) and a new MCU design (completely redone) to github and dropbox. Commit logs:

Added MSP430550x and TPDxe001 to project library
Minor: Moved SUSPEND label in FPGA design
Changed symbol to new entry in library, having better structure
Changed library and size of caps
Changed oscillator
Added USB filters and ESD protection according to SLAU278F

Also added symbols for the still-to-be-connected nets to the MCU design.

Olaf.Mandel

member

Activity: 70

Merit: 10

Quote from: O_Shovah on July 30, 2011, 05:22:13 PM

[...]
Ok, what else needs to be done to the MSP section?
I'll have a look to change the package tomorrow.
EDIT
Did i miss something ? In the version i uploaded the MSP 430 f 5507 has a RGZ package i thought we agreed to use this one. ?

Sorry, my mistake. I started working on the file and decided to copy the device into the project.lbr library. I only looked after doing the copy from the downloaded TI library.

You saw my previous comments on the MCU?

Topic: Modular FPGA Miner Hardware Design Development - page 7. (Read 119320 times)