Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Jan 9, 12:08=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > In comp.arch.fpga MitchAlsup <MitchAl...@aol.com> wrote:> On Jan 7, 8:38 = pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net> > > wrote: > >> Intel fabs are often ahead of TSMC and UMC and GF. But this doesn't > >> explain the whole difference, not by a long shot, especially given AMD= 's > >> situation. > > (snip) > > > Note: excepting for RAMs and ROMs, there is almost no dynamic logic in > > one of the x86 manufactures products. Dynamic logic is hard and takes > > a lot more designers to get right (some of them in the FAB.) Dynamic > > logic is sensitive to the process window swings. In many cases, > > dynamic logic is not really faster once you consider not being able to > > use the logic in the other 1/2 of the clock cycle and the added skew > > on the falling edge of the clock. > > The 8080 and 8086 used dynamic logic. =A0(Possibly only for registers.) > > One reason the Z80 became more popular than the 8080 was its use > of static logic, and the ability to debug with a slow clock. > > The processors with built-in PLL can't be slow clocked, even if > the logic is static. > > -- glen IIRC, somebody here (or was it Paul DeMone in one of his excellent RWT articles) explained that dynamic logic of today is different from dynamic logic of late 70s. From high level perspective today's dynamic logic could be described as pseudo-static. It works just fine with slow clocks.Article: 150301
On Jan 8, 11:29=A0pm, MitchAlsup <MitchAl...@aol.com> wrote: > > A good decision based on the power envelope not letting the speed of > dynamic logic to be utilized to its fullest. > > Mtich What you are saying sounds right for quad and hexacores. But what about duals? Here is the fastest Westmere-based dual-core: http://ark.intel.com/Product.= aspx?id=3D48504 73W at 3.6 GHz. Taking into account that same-generation hexacore runs at 130W/3.3 GHz things do look either timing path limited or limited by desire of the marketeers to avoid too big speed difference in favor of cheaper part.Article: 150302
In comp.arch.fpga Muzaffer Kal <kal@dspia.com> wrote: (snip, I wrote) >>The processors with built-in PLL can't be slow clocked, even if >>the logic is static. > What if the PLL is programmable and can be told to generate > a slow clock? What do you mean by slow? Unless one is allowed to supply an external capacitor, there is no way to make a PLL go as slow as you can clock the Z80. How about 1uHz? (or 1nHz or 1pHz?) At 1GHz, you can make an RC circuit with R=1Mohm, C=1fF, such that RC=1e-9s For 1uHz, R=1Mohm, C=1F. That isn't easy, even with an external capacitor! -- glenArticle: 150303
On Jan 9, 1:53=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > In comp.arch.fpga Muzaffer Kal <k...@dspia.com> wrote: > (snip, I wrote) > > >>The processors with built-in PLL can't be slow clocked, even if > >>the logic is static. > > What if the PLL is programmable and can be told to generate > > a slow clock? > > What do you mean by slow? > > Unless one is allowed to supply an external capacitor, there is > no way to make a PLL go as slow as you can clock the Z80. > > How about 1uHz? (or 1nHz or 1pHz?) > > At 1GHz, you can make an RC circuit with R=3D1Mohm, C=3D1fF, > such that RC=3D1e-9s > > For 1uHz, R=3D1Mohm, C=3D1F. =A0That isn't easy, even with an external > capacitor! > > -- glen I can imagine the utility of 1mHz, may be, even 0.1 mHz in some extreme cases where you want to take a deep thought between the clocks. But 1uHz? Can't see how it helps debugging. Normally, when one needs very slow clock he gets it by dividing VCO with counter. Today many off-the-shelf PLLs have counters built-in. Although I have to admit that I never seen PLL with built-in counter that was wide enough to produce 1mHz.Article: 150304
Hi ALL,
my name is Francesco Da Riva and I have recentely bought a Spartan
3A starter kit board.
I have find a strange issue that i not be abble to solve. I
created a very simple greater 2 bit than comparator and connect it
with the switch and the led on the board.
All work perfectelly a part of for the input 1001, the led should
be turn on but it is not.
I try to simulate it on iSim and in simulation all work ok.
Could you help me?
Regards
Francesco Da Riva
VHDL CODE:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
use IEEE.NUMERIC_STD.ALL;
-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity gt2 is
Port ( a : in STD_LOGIC_VECTOR (1 downto 0);
b : in STD_LOGIC_VECTOR (1 downto 0);
al : out STD_LOGIC_VECTOR (1 downto 0);
bl : out STD_LOGIC_VECTOR (1 downto 0);
agtb : out STD_LOGIC);
end gt2;
architecture sop_arch of gt2 is
signal p0, p1, p2, p3, p4, p5 : std_logic;
begin
agtb <= p0 or p1 or p2 or p3 or p4 or p5;
al <= a;
bl <= b;
p0 <= (not a(1)) and a(0) and (not b(1)) and (not b(0));
p1 <= a(1) and (not a(0)) and (not b(1)) and (not b(0));
p2 <= a(1) and (not a(0)) and (not b(1)) and b(0);
p3 <= a(1) and a(0) and (not b(1)) and (not b(0));
p4 <= a(1) and a(0) and (not b(1)) and b(0);
p5 <= a(1) and a(0) and b(1) and (not b(0));
end sop_arch;
CONSTRAINTS FILE
#========================================================
# buttons & switches
#========================================================
# 8 slide switches
NET "a<0>" LOC = "T9" | IOSTANDARD = LVCMOS33;
NET "a<1>" LOC = "U8" | IOSTANDARD = LVCMOS33;
NET "b<0>" LOC = "U10" | IOSTANDARD = LVCMOS33;
NET "b<1>" LOC = "V8" | IOSTANDARD = LVCMOS33;
#========================================================
# 8 discrete led
#========================================================
NET "agtb" LOC = "R20" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "al<0>" LOC = "W21" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "al<1>" LOC = "Y22" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "bl<0>" LOC = "V20" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "bl<1>" LOC = "V19" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
Article: 150305On Jan 8, 4:08=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > In comp.arch.fpga MitchAlsup <MitchAl...@aol.com> wrote:> On Jan 7, 8:38 = pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net> > > wrote: > >> Intel fabs are often ahead of TSMC and UMC and GF. But this doesn't > >> explain the whole difference, not by a long shot, especially given AMD= 's > >> situation. > > (snip) > > > Note: excepting for RAMs and ROMs, there is almost no dynamic logic in > > one of the x86 manufactures products. Dynamic logic is hard and takes > > a lot more designers to get right (some of them in the FAB.) Dynamic > > logic is sensitive to the process window swings. In many cases, > > dynamic logic is not really faster once you consider not being able to > > use the logic in the other 1/2 of the clock cycle and the added skew > > on the falling edge of the clock. > > The 8080 and 8086 used dynamic logic. =A0(Possibly only for registers.) I was talking about processor designed and FABed in the 2003-2010 time frame, not made by that company over the entire life of that architecture. Yes all the old stuff used dynamic logic. In 2.5 micron single metal process you had to use dynamic logic to even get the chip to fit in the die. Times have changed. Mitch MitchArticle: 150306
On Jan 9, 3:42=A0am, Michael S <already5cho...@yahoo.com> wrote: > On Jan 8, 11:29=A0pm, MitchAlsup <MitchAl...@aol.com> wrote: > > > > > A good decision based on the power envelope not letting the speed of > > dynamic logic to be utilized to its fullest. > > > Mtich > > What you are saying sounds right for quad and hexacores. But what > about duals? Q: How could a company afford do another core design that would be used in a dual processor? A: They cannot. The dual is the same core as the quad, it just gets to run in a more power rich environment. MitchArticle: 150307
On Jan 9, 11:05=A0am, Francesco Da Riva <use...@dariva.it> wrote: > Hi ALL, > > =A0 =A0 my name is Francesco Da Riva and I have recentely bought a Sparta= n > 3A starter kit board. > > =A0 =A0 I have find a strange issue that i not be abble to solve. I > created a very simple greater =A02 bit than comparator and connect it > with the switch and the led on the board. > > =A0 =A0All work perfectelly a part of for the input =A01001, the led shou= ld > be turn on but it is not. > > =A0 =A0I try to simulate it on iSim and in simulation all work ok. > > Could you help me? The first thing you should do is to break the problem into smaller pieces to try to isolate the problem. Generally there are three areas where your problem can lie, the input, the output or the processing. You can effectively separate the I/O from the processing by connecting one of the switches directly to the LED through the FPGA. If you test this with each of the four inputs and throwing the switches makes the LED go on and off, then your problem is in the logic of the code. If the LED does not toggle with the switches, then you either have a faulty switch or you have the I/O mapped to the wrong pins. Any time you have a problem that you can't trace to a logic problem, you need to simplify the situation to further isolate the bug. RickArticle: 150308
On 9 Gen, 18:52, rickman <gnu...@gmail.com> wrote: > The first thing you should do is to break the problem into smaller > pieces to try to isolate the problem. I made this tests : 1)Connect each led to each swith, all work properly. 2)Try the same code on anther board, same issue. > Any time you have a problem that you can't trace to a logic problem, > you need to simplify the situation to further isolate the bug. I agree with you but in this case I no be able to find any trouble in each single piece of the puzzle. Regards Francesco Da RivaArticle: 150309
Hello, I'm looking for the Xilinx ML561 schematics. Please share! Thanks in advanceArticle: 150310
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >In comp.arch.fpga Muzaffer Kal <kal@dspia.com> wrote: >(snip, I wrote) > >>>The processors with built-in PLL can't be slow clocked, even if >>>the logic is static. > >> What if the PLL is programmable and can be told to generate >> a slow clock? > >What do you mean by slow? > >Unless one is allowed to supply an external capacitor, there is >no way to make a PLL go as slow as you can clock the Z80. Bypassing the PLL is a common trick / feature. Many modern processors allow clocking through the JTAG interface for flash programming an debugging purposes. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 150311
On Jan 9, 2:18=A0pm, Francesco Da Riva <use...@dariva.it> wrote: > On 9 Gen, 18:52, rickman <gnu...@gmail.com> wrote: > > > The first thing you should do is to break the problem into smaller > > pieces to try to isolate the problem. > > I made this tests : > 1)Connect each led to each swith, all work properly. > 2)Try the same code on anther board, same issue. > > > Any time you have a problem that you can't trace to a logic problem, > > you need to simplify the situation to further isolate the bug. > > I agree with you but in this case I no be able to find any trouble in > each single piece of the puzzle. > > Regards > =A0 =A0Francesco Da Riva Sherlock Holmes says that "once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth". The only thing left is your logic. You have a number of partial products in your code. Bring each of them out to the LEDs. If they work ok, then combine them again. I don't know what the polarity of the LEDs are. Did you try combinations of switches that would both make the LED light and go out? This is not magic. But sometimes the solution is not obvious. In those cases you have to gather more information to know enough to figure out the problem. RickArticle: 150312
On Jan 8, 5:50=A0am, Muzaffer Kal <k...@dspia.com> wrote: > On Fri, 07 Jan 2011 07:24:21 -0600, "karl.bengtsson" > > > > <karl.bengtsson@n_o_s_p_a_m.norspace.no> wrote: > >Hello. > > >I have a design targeting the (ancient, perhaps) Actel A54SX32A. During > >testing I exposed several of the input pins to signals with extremly low > >slewrate, using a power-supply to supply the input. This was most likely > >way outside the minimum slewrate requrements for the device. > > >The FPGA seems to be working and it passes all functional tests, but the > >current to the core is way to large at about 70mA. Sadly, I did not meas= ure > >the current beforehand and the cost of a new (ceramic) FPGA prohibits me > >from just burning a new one to test that. A freshly burned plastic FPGA > >works fine and consumes the expected current. > > >Does anyone have any experience with destroying FPGAs due to low slewrat= es? > >Is this even probable? > > CMOS structures are push-pull ie they have two switches which > "simultanenously" turn-on/off to change state; alas the switching is > never instantenous so there is overlap so dynamic current flows during > the switch. The worst case current is near the middle voltage level, > the longer you stay around that point the higher the average current. > It's possible to destroy individual IOs by leaving unconnected inputs > and letting them float. Your case is not as extreme but would affect > lifetime of the IO. Which part numbers have you actually seen this occur on ? Your explanation is correct, that there is a Icc peak (or double Icc peak on a Schmitt pin), but that is usually in the sub mA region, and so will struggle to generate more than 1mW of heating in each FET. eg look at NXP 74AUP2T1326, which gives a classic schmitt Icc plot, twin peaks at 150uA & 200uA, 1.8V testcase. A NXP 74LVU04 shows over 200uA @ 1.2V and > 1mA @3V, but that if for Output Drive fets, (~ 40 ohms) Another Digital-Pin effect, is not the current of a linear buffer, but the parasitic transition oscillations that can occur, when there is no hysteresis, and a multiple buffers hit the 'linear' region. I have seen the chip-wide effects of that, yield high Icc levels, and also give 'crosstalk' effects, where supposedly logically independent pathways, jitter as a result of this. (common mode inductance). This would (over?) heat a larger portion of the chip. So the advice is don't float (non schmitt) pins, but has anyone seen physical/permanent damage/degrade from these effects ? -jgArticle: 150313
On 9 Gen, 22:31, rickman <gnu...@gmail.com> wrote: > On Jan 9, 2:18=A0pm, Francesco Da Riva <use...@dariva.it> wrote: > > > > > On 9 Gen, 18:52, rickman <gnu...@gmail.com> wrote: > > > > The first thing you should do is to break the problem into smaller > > > pieces to try to isolate the problem. > > > I made this tests : > > 1)Connect each led to each swith, all work properly. > > 2)Try the same code on anther board, same issue. > > > > Any time you have a problem that you can't trace to a logic problem, > > > you need to simplify the situation to further isolate the bug. > > > I agree with you but in this case I no be able to find any trouble in > > each single piece of the puzzle. > > > Regards > > =A0 =A0Francesco Da Riva > > Sherlock Holmes says that "once you eliminate the impossible, whatever > remains, no matter how improbable, must be the truth". :-) >=A0The only thing left is your logic. But in simulation the wave form work ok for any Input combination. =A0I don't know what the polarity of the LEDs are. > Did you try combinations of switches that would both make the LED > light and go out? All combination work properly instead of 1001 combination. In my code is the p2 signal. Regards FrancescoArticle: 150314
On 1/7/2011 8:38 PM, Andy "Krazy" Glew wrote: snip > > Intel fabs are often ahead of TSMC and UMC and GF. But this doesn't > explain the whole difference, not by a long shot, especially given AMD's > situation. > > By the way, an interesting conversation is why IBM is above 5GHz, > whereas Intel is not. > > snip My first guess would be that SOI had something to do with it. Second would be packaging and higher power budget. Third might be because it was a no holds barred high end design while Intel had other constraints. Don't know for sure. And I know that there are differences of opinion about SOI and its leverage at various process nodes. -- delArticle: 150315
On Jan 9, 5:25=A0pm, Francesco Da Riva <use...@dariva.it> wrote: > On 9 Gen, 22:31, rickman <gnu...@gmail.com> wrote: > > > > > On Jan 9, 2:18=A0pm, Francesco Da Riva <use...@dariva.it> wrote: > > > > On 9 Gen, 18:52, rickman <gnu...@gmail.com> wrote: > > > > > The first thing you should do is to break the problem into smaller > > > > pieces to try to isolate the problem. > > > > I made this tests : > > > 1)Connect each led to each swith, all work properly. > > > 2)Try the same code on anther board, same issue. > > > > > Any time you have a problem that you can't trace to a logic problem= , > > > > you need to simplify the situation to further isolate the bug. > > > > I agree with you but in this case I no be able to find any trouble in > > > each single piece of the puzzle. > > > > Regards > > > =A0 =A0Francesco Da Riva > > > Sherlock Holmes says that "once you eliminate the impossible, whatever > > remains, no matter how improbable, must be the truth". > > :-) > > >=A0The only thing left is your logic. > > But in simulation the wave form work ok for any Input combination. > > =A0=A0I don't know what the polarity of the LEDs are. If you don't know the polarity, how do you know when it should be on vs off? > > Did you try combinations of switches that would both make the LED > > light and go out? > > All combination work properly instead of 1001 combination. > In my code is the p2 signal. I think you are saying that you have been able to activate p0, p1, p3, p4, p5 and the LED lights up? When you input the other nine combinations, is the LED off? If one of those causes the LED to light, there is something wrong with your assumptions. I see you pass the switch inputs back out of the chip. I assume each of those drives an LED that lights when you expect it to? There is something wrong, either with your circuit or your assumptions. Keep tearing it apart until you find something wrong you can put your finger on. I think the hardest debug I've ever done was this past summer. The design was only a little complex, but I had a few bugs that had gotten past simulation. These were all found in testing with my customer. Finally we had one problem that defied logic. Because it shouldn't have been happening, it was very hard to add debug code to try to figure out what the problem was. I went by the customer's site at least twice a week for a couple of weeks and was making no ground. In the third week I had some heavy duty code inserted into the design and found that the PLL was acting as if it had not been initialized. We had already gone over the initialization a couple of times and I verified that he was doing it right... or so I thought. Turns out even though we had gone over it at least twice, he had not done one step that loaded the registers in the PLL. The point is, when debugging, challenge all of your assumptions. RickArticle: 150316
On Jan 10, 5:05 am, Francesco Da Riva <use...@dariva.it> wrote: > Hi ALL, > > my name is Francesco Da Riva and I have recentely bought a Spartan > 3A starter kit board. > > I have find a strange issue that i not be abble to solve. I > created a very simple greater 2 bit than comparator and connect it > with the switch and the led on the board. > > All work perfectelly a part of for the input 1001, the led should > be turn on but it is not. Look at the report files, and check the reduced logic (try more than one target) Should be along the lines of this agtb = ((!b_1 & a_1) # (a_0 & !b_0 & a_1) # (a_0 & !b_0 & !b_1)); If it sims, this has high probability of being what you see. Next, draw a table of ALL the bench-test values, (as here you do not have many) - then work backwards to see what has dropped, or been miss- mapped. My guess is, you have a_1, a_0 swapped, and you forgot to test all the expected-negative cases as well ? ;) -jgArticle: 150317
> Which part numbers have you actually seen this occur on ? > My device is an A54SX32SA-208CQFP. A freshly burned A54SX32SA-208PQFP shows normal current consumption. I understand how leaving the voltage at an incorrect level will cause current to flow in the input, which could cause excessive heating. But how would this translate into an permanent increase in current on the core supply? Some additional findings. I desoldered (well, someone did it for me) the VCCA pins of the FPGA to see if there where any difference between them. I then connected them one-by-one and looked at the current delivered. A few of the pins showed a stable, high, current consumption. While a couple of others varied wildly for a few seconds before settling to the same, high, current consumption. I have no idea if this tells anyone anything, but I felt it was worth noting. Anyhow, thanks everyone for the replies so far! :) --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150318
Alright, I admit changing the name of the entity after pasting, cause the
original name was not related to the function.
Also, what is missing in your attempt is:
use ieee.std_logic_unsigned.all;
Which I assumed was very common and didn't include. Sorry for that.
"KJ" <kkjennings@sbcglobal.net> wrote in message
news:872e6dca-2257-432c-95b7-1fc9ab2a0b09@m37g2000vbn.googlegroups.com...
On Jan 7, 4:07 am, "Morten Leikvoll" <mleik...@yahoo.nospam> wrote:
> >> The code below is some tested and implemented code I found on my drive.
>
> NO, ieee.std_logic_arith.all was not in my code. Did you try it?
>
Yes, I did...apparently you did not, even though you called it "tested
and implemented code I found on my drive".
Quartus 10.0 SP1 reports the following error on the statement
"testcnt<=testcnt+"1"; "
Error (10327): VHDL error at Junk.vhd(341): can't determine definition
of operator ""+"" -- found 0 possible definitions
Modelsim 6.4 reports the following (as I mentioned in the first post)
No feasible entries for infix operator "+".
But before you get those errors, you'll have to clean up another error
because you used the name 'test' as the name of the entity and as a
signal.
architecture rtl of test is
...
test<='0';
As I suggested in my first post, you might want to try out your code
first before posting.
KJ
Article: 150319On Jan 10, 8:53=A0pm, "karl.bengtsson" > But how would this translate into an permanent increase in current on the > core supply? > > Some additional findings. I desoldered (well, someone did it for me) the > VCCA pins of the FPGA to see if there where any difference between them. = I > then connected them one-by-one and looked at the current delivered. A few > of the pins showed a stable, high, current consumption. While a couple of > others varied wildly for a few seconds before settling to the same, high, > current consumption. So you are saying the device(s?) work ok, but just have higher currents ? Are you also saying that higher Icc, is evenly spread over Banks, even with no floating pins and a static clock ? -jgArticle: 150320
On Jan 10, 8:53=A0am, "karl.bengtsson" <karl.bengtsson@n_o_s_p_a_m.n_o_s_p_a_m.norspace.no> wrote: > > Which part numbers have you actually seen this occur on ? > > My device is an A54SX32SA-208CQFP. A freshly burned A54SX32SA-208PQFP sho= ws > normal current consumption. > > I understand how leaving the voltage at an incorrect level will cause > current to flow in the input, which could cause excessive heating. > > But how would this translate into an permanent increase in current on the > core supply? > > Some additional findings. I desoldered (well, someone did it for me) the > VCCA pins of the FPGA to see if there where any difference between them. = I > then connected them one-by-one and looked at the current delivered. A few > of the pins showed a stable, high, current consumption. While a couple of > others varied wildly for a few seconds before settling to the same, high, > current consumption. > I have no idea if this tells anyone anything, but I felt it was worth > noting. > > Anyhow, thanks everyone for the replies so far! :) > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com It looks like that part was irradiated by particles during a test beam. This is a OTP FPGA. That Actel's family is used in the satellites/ rockets/airplane as also in particle physics experiments and usually are submitted to radiation test. After radiation, one major TID effect is an augment of leakage current in CMOS that is what you observe. So the question are: where this Ic come from ? Could it been irradiated ? It is only a hypothesis but it is better to have care in managing that part. FabioArticle: 150321
Hi All!!!
I found it!!!
I test with this architecture
architecture boolean_arch of gt2 is
begin
agtb <= '1' when a>b else '0';
al <= a;
bl <= b;
end boolean_arch;
but the problem remian identical so I cheked the UCF file and find the
problem!!!
I mapped the switch bad, with the MSB on the right side :-)
This is the right UCF:
========================================================
# buttons & switches
#========================================================
# 8 slide switches
NET "a<1>" LOC = "T9" | IOSTANDARD = LVCMOS33;
NET "a<0>" LOC = "U8" | IOSTANDARD = LVCMOS33;
NET "b<1>" LOC = "U10" | IOSTANDARD = LVCMOS33;
NET "b<0>" LOC = "V8" | IOSTANDARD = LVCMOS33;
#========================================================
# 8 discrete led
#========================================================
NET "agtb" LOC = "R20" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "al<1>" LOC = "W21" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "al<0>" LOC = "Y22" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "bl<1>" LOC = "V20" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
NET "bl<0>" LOC = "V19" | IOSTANDARD = LVCMOS33 | SLEW = SLOW | DRIVE
= 8;
Thanks to all for the support
Regards
Francesco Da Riva
Article: 150322Hello everyone, I have recently begun a project in which I would like to add an Ethernet interface to my spartan-3e FPGA allowing it to receive commands from one of two computers on a local network. Currently, I am using the Digilent Basys 2 starter board along with the pmod Ethernet NIC offered by Digilent. This pmod contains a PHY/MAC chip with an SPI interface. My question relates to the needed coding on the FPGA. I have been searching around and found that many people use Microblaze to simulate a microprocessor on the FPGA, however I am largely unfamiliar with this and was wondering if there was a way to use straight VHDL to simply receive data from the PHY/MAC chip? From my understanding my device will not need to use IP since I have no need to send data over the internet so I could technically treat the PHY/MAC chip as a memory register that I would read and write to, correct? Thank you in advance. -Andrew --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150323
On 01/10/2011 08:19 AM, buddylee9898 wrote: > Hello everyone, I have recently begun a project in which I would like to > add an Ethernet interface to my spartan-3e FPGA allowing it to receive > commands from one of two computers on a local network. Currently, I am > using the Digilent Basys 2 starter board along with the pmod Ethernet NIC > offered by Digilent. This pmod contains a PHY/MAC chip with an SPI > interface. > > My question relates to the needed coding on the FPGA. I have been searching > around and found that many people use Microblaze to simulate a > microprocessor on the FPGA, however I am largely unfamiliar with this and > was wondering if there was a way to use straight VHDL to simply receive > data from the PHY/MAC chip? From my understanding my device will not need > to use IP since I have no need to send data over the internet so I could > technically treat the PHY/MAC chip as a memory register that I would read > and write to, correct? Thank you in advance. How much parsing will you need to do of the information from the PHY/MAC? If you just need to do some setup, then read from one memory location over and over (which means that you'd be using low-level Ethernet in some exceedingly simple fashion) then -- maybe. I'm not an FPGA whiz, but I've done a bit of work in them. Both times the problem said "processor", but the customer said "no processor". You end up with these gawdaful state machines that grow without bound, have lots of synthesis gotchas (at least when I do them), and as a consequence are maintenance nightmares. At least when I do them I end up with more lines of HDL than I would of assembly code to do it on a processor. Perhaps a better man than I could make these work and be maintainable -- but perhaps a better man than I could just convince the customer that yes, a processor is really what's needed. Were it me I would hesitate to make the mistake _again_, and I'd figure that the up-front work of figuring out how to shove a processor in there is going to be less than the subsequent work of maintaining a processor-less nightmare of my own creation. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 150324
On 10 Jan., 11:47, F M <fmon...@gmail.com> wrote: > On Jan 10, 8:53=A0am, "karl.bengtsson" > > > > <karl.bengtsson@n_o_s_p_a_m.n_o_s_p_a_m.norspace.no> wrote: > > > Which part numbers have you actually seen this occur on ? > > > My device is an A54SX32SA-208CQFP. A freshly burned A54SX32SA-208PQFP s= hows > > normal current consumption. > > > I understand how leaving the voltage at an incorrect level will cause > > current to flow in the input, which could cause excessive heating. > > > But how would this translate into an permanent increase in current on t= he > > core supply? > > > Some additional findings. I desoldered (well, someone did it for me) th= e > > VCCA pins of the FPGA to see if there where any difference between them= . I > > then connected them one-by-one and looked at the current delivered. A f= ew > > of the pins showed a stable, high, current consumption. While a couple = of > > others varied wildly for a few seconds before settling to the same, hig= h, > > current consumption. > > I have no idea if this tells anyone anything, but I felt it was worth > > noting. > > > Anyhow, thanks everyone for the replies so far! :) > > > --------------------------------------- =A0 =A0 =A0 =A0 > > Posted throughhttp://www.FPGARelated.com > > It looks like that part was irradiated by particles during a test > beam. > This is a OTP FPGA. That Actel's family is used in the satellites/ > rockets/airplane as also in particle physics experiments =A0and usually > are submitted to radiation test. > After radiation, one major TID effect is an augment of leakage current > in CMOS that is what you observe. > > So the question are: > where this Ic come from ? > Could it been irradiated ? > > It is only a hypothesis but it is better to have care in managing that > part. The A54xxx is the commercial device without radiation hardening. Would not expect any irradiation of this device expecially not in device screening process, as rad tests are not part of device screening only qualification (means the design is irradiated, not the delivered device). Screening should only cover a burn-in for each device (normal for a RT54 device, don't know if some mil flow covers burn-in). For the RT54SXxxS devices from MEC there was an issue with inrush during power cycling. Don't know if commercial device could have the same issue as it is different silicon with AFAIK different process than RT device. bye Thomas
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z