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 17 Okt., 19:46, Philip Potter <p...@see.sig.invalid> wrote:
> Hello all,
>
> I'm using EDK 9.1.02i to develop an application for the Xilinx
> University Program Virtex-II Pro board.
>
> I created a bare MicroBlaze project and ran the following program on it:
>
> #include <stdio.h>
>
> int main(void) {
> unsigned int i = 10;
> xil_printf("Signed: %d Unsigned: %u\r\n",(int) i, i);
> return 0;
>
> }
>
> The output (over the serial port) was this:
>
> Signed: 10 Unsigned:
>
> Apparently xil_printf() ignores the %u format specifier. What's going on?
>
> --
> Philip Potter pgp <at> doc.ic.ac.uk
xil_printf has limited support for the formats, check it out what is
supported
Antti
Article: 125201Antti, Could you fix the typo on the line with the do64(62 downto 0) assignment - there's an array length mismatch. Also, what is the definition of do64 - std_logic_vector(63 downto 0)? On Oct 17, 4:44 pm, Antti <Antti.Luk...@googlemail.com> wrote: > Hi ho > > here is code > > process (m_sck) begin > if (m_sck'event and m_sck=3D'1') then > do64(62 downto 0) <=3D do64(62 downto 0) & M_DI; > end if; > end process; > LEDS <=3D do64s(63 downto 60); > > M_DI, M_SCK are driven by external MCU SPI interface. > the MCU send either > 0x90 00 00 00 00 00 00 00 > or > 0x00 00 00 00 00 00 00 00 > > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1 > when the FPGA is full, there will blink all off, then 1-1-0-1 > repeating same pattern, not randomness > > changing maxfanout in synplify will change the erratic behaviour but I > have not managed to get the shift register ever work in case where > FPGA is really full. > > SPI clock is 4MHz (or lower doesn seem to make any difference) > > this time I am giving up, that is not trying to force the shift > register to work, but find solution that works > > the problem only occourcs on Actel FPGA, and yes yes it works in > s=EDmulation it works in xilinx FPGA, etc.. > > Antti > who this time really doesnt know the solution :(Article: 125202
On 17 Okt., 23:15, Dave <dhsch...@gmail.com> wrote:
> Antti,
>
> Could you fix the typo on the line with the do64(62 downto 0)
> assignment - there's an array length mismatch. Also, what is the
> definition of do64 - std_logic_vector(63 downto 0)?
>
> On Oct 17, 4:44 pm, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > Hi ho
>
> > here is code
>
> > process (m_sck) begin
> > if (m_sck'event and m_sck=3D'1') then
> > do64(62 downto 0) <=3D do64(62 downto 0) & M_DI;
> > end if;
> > end process;
> > LEDS <=3D do64s(63 downto 60);
>
> > M_DI, M_SCK are driven by external MCU SPI interface.
> > the MCU send either
> > 0x90 00 00 00 00 00 00 00
> > or
> > 0x00 00 00 00 00 00 00 00
>
> > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1
> > when the FPGA is full, there will blink all off, then 1-1-0-1
> > repeating same pattern, not randomness
>
> > changing maxfanout in synplify will change the erratic behaviour but I
> > have not managed to get the shift register ever work in case where
> > FPGA is really full.
>
> > SPI clock is 4MHz (or lower doesn seem to make any difference)
>
> > this time I am giving up, that is not trying to force the shift
> > register to work, but find solution that works
>
> > the problem only occourcs on Actel FPGA, and yes yes it works in
> > s=EDmulation it works in xilinx FPGA, etc..
>
> > Antti
> > who this time really doesnt know the solution :(- Zitierten Text ausble=
nden -
>
> - Zitierten Text anzeigen -
sorry my eyes see double(almost, just hurt), i cleaned the code and
madetypo
signal do64 : std_logic_vector(63 downto 0) ;
process (m_sck) begin
if (m_sck'event and m_sck=3D'1') then
do64(63 downto 0) <=3D do64(62 downto 0) & M_DI;
end if;
end process;
LEDS <=3D do64(63 downto 60);
Article: 125203On Oct 16, 2:35 pm, Eric Smith <e...@brouhaha.com> wrote: > "Amontec, Larry" <laurent.ga...@ANTI-SPAMamontec.com> writes: > > Is whishbone bus a multi-master bus ? > > Not in the conventional sense. It's not well-suited for an off-chip > interconnect. You may want to check out the "J" mode bus on the local bus side of various PLX bridges (9000 series and 8311). This is fairly simple compared to PCI and came from a standard microprocessor bus. The PLX part datasheets have lots of timing diagrams showing bus operation under all sorts of conditions. Cheers, GaborArticle: 125204
Michel, ES = "engineering sample" This is what we call parts BEFORE they are qualified for production. In some cases, ES parts are completely identical to the final production, and in other cases, they are not identical (they have known bugs or problems we call "errata"). CES = "commercial grade engineering sample" (it has a speed grade) Go look for V5 errata at: http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?iLanguageID=1&category=-1212267&sGlobalNavPick=&sSecondaryNavPick= to find the exact differences. If you have questions about any of these errata, please contact your distributor or Xilinx FAE. We sell ES parts to customers early in order to give them a head-start on their design and debugging (over their competition). The risk of purchasing an ES part, is they may have bugs (known, as detailed in the errata, or as of yet unknown, as all testing may not be complete nor all test programs in place). If the parts have bugs, there is no warranty (they are non-returnable, non-refundable). The normal warranties do not apply to an ES part. As an example, ES parts are never accepted for a "RMA" (returned merchandise authorization) or for F/A (failure analysis). It is recommended that ES never be used for production product. If used for production product, the purchaser must accept all of the risks, as Xilinx has stated these parts are not intended nor recommended for production product. This is pretty standard practice in the industry, and is not unique to FPGA technology either. AustinArticle: 125205
On Oct 17, 1:52 pm, michel.ta...@gmail.com wrote: > Hi alls, > > I've a question which seems stupid, but I don't find answer anywhere.. > ( maybe I don't search correctly ) > What is the difference between XC5VLX50-1FFG676C and > XC5VLX50-1FFG676CES ? I don't understand what does 'ES' mean at the > end of the FPGA reference .. > > So, please, if anyone knows.. > > Thanks by advance, > > best regards, Michel. Look here: <http://www.xilinx.com/xlnx/xweb/ xil_publications_display.jsp?category=Errata/FPGA+Device+Families/ Virtex-5> The link was found by doing a search for XC5VLX50-1FFG676CES on the Xilinx web site. G.Article: 125206
John_H wrote:
> Neil Steiner wrote:
>> When generating EDIF from Synplify, I frequently notice buffers
>> (LUT1_L primitives with INIT property of 2) inserted in the circuit.
>> Does anybody know why the tool is doing this and/or whether it can be
>> disabled?
>>
>> [snipped]
Thanks for the response, John.
> While the INIT property of 2 leaves me a little confused (I would expect
> 1 or 0 for a LUT1) ...
Let's see if I can get this right. A 1-input LUT is a 2-bit RAM. In
the case of a buffer, the 10 (binary) value gets replicated as
1010101010101010 and inverted to 0101010101010101. The MSB of that word
is addressed when all inputs are zero, so {A1,A2,A3,A4}={0,0,0,0}
returns 0. More generally, {A1,A2,A3,A4}={0,x,x,x} returns 0, and
{A1,A2,A3,A4}={1,x,x,x} returns 1. It's this weird LUT math thing ... ;)
> ... the presence of "glorified pass-through" elements are often
> required to drive carry chains properly.
... and I will concede that there are carry chain elements on nearby
nets ...
> Do you know the structure of the slice very well?
I do. That's not to say I can't be making a mistake, but I'm quite
familiar with the FPGA Editor view, as well as the rules about what can
and cannot be mixed and matched within a slice. (Not all of the actual
rules are apparent from the FPGA Editor view.) From a slice component
perspective, I have yet to find a situation where these buffers were
strictly required. Or stated differently, even though I trim the
buffers, the implementations still work properly in hardware.
> I have a graphic of the slice internals pinned to my cubicle wall to
> refer to anytime I see something odd in my Synplify HDL Analyst
> technology view, usually because my coding comes up with something
> that doesn't fit the way I expect with the tool most often doing the
> right thing for the RTL I've presented. I usually just need to tweak
> my thinking and the code to get the "clean" results I thought I'd get
> the first round.
That does make sense, but I'm seeing behavior like this even in the
trivially simple case of a 32-bit counter:
process(clk)
begin
if rising_edge(clk) then
if reset = '1' then
reg <= (others => '0');
else
reg <= reg + 1;
end if;
end if;
end process;
I can't really tweak that code without instantiating a carry chain
structurally. So I remain puzzled about the behavior, though I do
appreciate your comments. Apart from research purposes (my case), I
assume that the Xilinx tools are the only consumer of Synplify EDIF
(when targeting Xilinx parts), so I half wonder whether there's some
kind of dependency thing going on with the two tools, possibly for
legacy reasons ...
Article: 125207
Andy wrote:
> While it is possible to raise the level of abstraction using single
> processes, variables, functions, etc., the description must still be
> explicitly about what happens in each and every clock cycle.
That is the downside, but that is
also the ticket to easy synthesis.
If I can't get n:=n+1; done in
one clock cycle, I have to break
up the variables and declare
a counter or enumeration
to update and case.
But I expect that an embedded C programmer
who has written an interrupt routine would get it
for control logic and simple math.
It might even placate Maroc's boss :)
I agree that complicated DSP requires some
sort of algorithm generator like matlab or Catapult
(and thanks for the catapult tutorial by the way)
> Even some
> simple cases of retiming can allow one to describe an operation that
> will take place over a specific number of clock cycles, but you have
> little or no control over the resulting division of the circuit across
> clock cycles.
I don't see that as a downside as long as
the simulation matches at the ports.
> ... Catapult is clearly a datapath tool; it does not handle
> arbitrary control logic very well.
And this is where plain-old vhdl is more than good enough.
-- Mike Treseler
Article: 125208hans64@ht-lab.com pisze: > On Oct 17, 11:40 am, Maroc <md2...@libero.it> wrote: >> Thanks. >> >> In Xcell Journal the proposed tool are "function-specific" or oriented >> to Hardware Acceleration. >> >> I'm looking for a work flow to develop generel purpose FPGA function, >> starting from high level description. >> >> For example I'd like to start from "C-model" or "MATLAB model" or "?!? >> model" and by using efficent compiler obtain a synthesizable RTL code. >> >> I don't know this world (I always used VHDL or block diagram)...plese >> be patient! >> >> thanks, thanks > > There are a number of tools that operate in the ESL/synthesis space, > however, you need a serious EDA budget to get any of these tools. In > addition to this these tools are not general purpose and they normally > operate well in a particular niche area (e.g. DSP/datapath). You > already mentioned Catapult that can synthesize C/C++ to HDL (Verilog/ > VHDL), other tools like Catalytic can convert M-Code to C, tools like > SystemCrafters/ForteDS/BlueSpec/Agility/etc allow you to go from > SystemC to HDL but as I mentioned, these tools are not cheap, work in > a niche area and require specialist knowledge to drive them well. > > Hans > www.ht-lab.com > Maybe AutoPilot tool is cheaper ? It converts high-level C/C++/SystemC code to RTL. see http://www.autoesl.com/product.html P.Article: 125209
Synplify has changed how they do this several times over the years. I'm pretty sure they insert the buffers if the logic preceding the carry chain would cause the carry chain to be broken by the optimization without the lut buffers. They had a problem with earlier releases where a constant on one of the bit inputs to the carry chain would cause the carry chain to be broken into two segments, which made for some pretty ugly mappings. The LUT1 mapping though does occasionally cause problems, notably when there is an instantiated or keep-buffered lut (done to strongly hint to the synthesis that you want it done in a particular way) followed by an inferred carry chain.Article: 125210
parekh.sh@gmail.com wrote: > Typically, each 8 bits of DQ and corresponding DM bit are grouped > together with an associated DQS bit. The idea is that individual pins > in this group will see similar skews. Therefore, the DQS to data/dm > relationship will not suffer at the memory or fpga. If you are going > to be running at the max rated operating frequency it would be > important to keep the group as suggested. Thanks for response. -- pgwArticle: 125211
Antti wrote: > On 17 Okt., 19:46, Philip Potter <p...@see.sig.invalid> wrote: >> Apparently xil_printf() ignores the %u format specifier. What's going on? >> > > xil_printf has limited support for the formats, check it out what is > supported Hi antti, Thanks for your answer. Where would I find such documentation? I've checked in the OS and libraries reference manual, but that only has a brief description and doesn't mention unsigned. -- Philip Potter pgp <at> doc.ic.ac.ukArticle: 125212
austin wrote: > As an example, ES parts are never accepted for a "RMA" (returned > merchandise authorization) Makes perfect sense. > or for F/A (failure analysis). You guys don't want to determine why ES parts fail? That seems really strange.Article: 125213
Antti wrote:
> signal do64 : std_logic_vector(63 downto 0) ;
> process (m_sck) begin
> if (m_sck'event and m_sck='1') then
> do64(63 downto 0) <= do64(62 downto 0) & M_DI;
> end if;
> end process;
> LEDS <= do64(63 downto 60);
What a maintenance nightmare!!
process (m_sck)
variable do64 : std_logic_vector(63 downto 0);
begin
if m_sck'event and m_sck = '1' then
do64 := do64(do64'left-1 downto 0) & M_DI;
end if;
LEDS <= do64(do64'left downto do64'left-3);
end process;
--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Article: 125214Antti wrote: > M_DI, M_SCK are driven by external MCU SPI interface. Sounds to me like you've got skew between M_DI & M_SCK at the shift-register clk, data inputs. Your evidence suggests that M_DI lags M_SCK... can you super-sample the inputs (they're only 4MHz) and adjust for the skew internally? Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 125215
Neil Steiner wrote: <snip>> > That does make sense, but I'm seeing behavior like this even in the > trivially simple case of a 32-bit counter: > > process(clk) > begin > if rising_edge(clk) then > if reset = '1' then > reg <= (others => '0'); > else > reg <= reg + 1; > end if; > end if; > end process; > > I can't really tweak that code without instantiating a carry chain > structurally. So I remain puzzled about the behavior, though I do > appreciate your comments. Apart from research purposes (my case), I > assume that the Xilinx tools are the only consumer of Synplify EDIF > (when targeting Xilinx parts), so I half wonder whether there's some > kind of dependency thing going on with the two tools, possibly for > legacy reasons ... In Verilog, I'd rearrange the equation to always add one to a value that's dependent on the synchronous reset such as always @(posedge clk) reg <= (reset ? -1 : reg) + 1; but since VHDL doesn't have a conditional operator (?) I'd do the assignment outside the synchronous process, still adding one whether the reset is asserted or not, the init coming through the "other" addend of -1. It's not so much that Synplify can't optimize logic extremely well, it's that it doesn't do math with foresight. It's often a matter of rearranging the math to make the adders come out as "simple" adders. It could be that if both sides of your if/else added the invert of reset, the synthesizer would recognize the structure and "do the right thing." Expecting the synthesizer to do rudimentary algebra is something I'd like to see, but perhaps asking a smidgen too much. Oh - and I understand the LUT1 INIT of 2 now. I know this stuff, it just gets hazy when I've been away from INITs for a few months. Any recent manual INITs I've done with binary equations from constants I0=aaaa, I1=cccc, I2=f0f0, and I3=ff00 with LUT4s. - John_HArticle: 125216
On 18 Okt., 03:19, Mark McDougall <ma...@vl.com.au> wrote: > Antti wrote: > > M_DI, M_SCK are driven by external MCU SPI interface. > > Sounds to me like you've got skew between M_DI & M_SCK at the > shift-register clk, data inputs. > > Your evidence suggests that M_DI lags M_SCK... can you super-sample the > inputs (they're only 4MHz) and adjust for the skew internally? > > Regards, > > -- > Mark McDougall, Engineer > Virtual Logic Pty Ltd, <http://www.vl.com.au> > 21-25 King St, Rockdale, 2216 > Ph: +612-9599-3255 Fax: +612-9599-3266 Mark, I was evidencing the complete design to fail to operate in the target FPGA same design was known to work in simulation and in other FPGA family as well. the 4MHz SPI signals are "near perfect" there is the clock alignment on the inputs is defenetly perfect. I a sampling at correct clock edge as well. The SPI clock shows little overshoot but thats all now what made the puzzle harder, at initial testing when i wasnt 100% of the SPI modes, etc, it looked like the 64 bit register would hold correct value, 1 bit shifted, as if the SPI master sends always 1 extra clock. to correct this and aligne data I did take added flip flop. stupid, but it seemed to work. and yes i had to add the 65th clock pulse in simulation testbench too. After that it looked like ok. but the complete design still failed to fully operate. now, the upper 4 bits of the register are used to "change mode" depending on the value, the mode change did not work. as FPGA has been is 80-98% full, so I used LEDs and UJTAG for debugging. connected "mode detect" to LED, wrong, then connected mode_detect to UIREG6 - this is where the problem described in quiz1 appeared!! before going totally nuts, I finally removed the rest of the logic around the shift the register, and the it id start to work and shift properly. playing around with maxfanout and global treshold in Synplify does seem to have influence how wrong the shift register shifts, but I had to time to go on forever trying to find a fanout-treshold values that would make all work. during testing with 4LED on shiftregister in big design, when it failed the same wrong (1-1-0-1 instead 1-0-0-1) patter was observable in all supply range where the board did stay operational, to my surprise the PCB FPGA+AVR MCU did work down to 1.7V and down to 1.7V the shift-led did show 1101 so the huge supply variation did make a difference. I assume the AVR generated signal did change a lot in amplitude, slew, overshoot, etc at lower supply, also AVR clock lowered maybe 2 times, but that all did not make any difference. so whatever causes the bad shift its very stable in given P&R run. as I said, I have no plausible explanation or cure. I did give up, and optimized the 64 bit register (it was holding a blowfish key challenge) away - and problem has disappeared as well. but it leaves an un-easy feeling, if the FPGA was working wrong because of unexplained reason, the same or similar reason could cause new trouble somewhere else too. the big desing has 1 parallell, 2 SPI slave, 2 SPI master, 1 sd card master interface, 6 global and 1 quadrant clock are used there is 50MHz free running clock, yes I tried to oversample and moreover glitch filter the SPI clock for the failing register, first trial did not give any result or improvement, and I did give up on that direction, the direct clocking looked as working better AnttiArticle: 125217
On 17 Oct, 21:44, Antti <Antti.Luk...@googlemail.com> wrote: > Hi ho > > here is code > > process (m_sck) begin > if (m_sck'event and m_sck=3D'1') then > do64(62 downto 0) <=3D do64(62 downto 0) & M_DI; > end if; > end process; > LEDS <=3D do64s(63 downto 60); > > M_DI, M_SCK are driven by external MCU SPI interface. > the MCU send either > 0x90 00 00 00 00 00 00 00 > or > 0x00 00 00 00 00 00 00 00 > > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1 > when the FPGA is full, there will blink all off, then 1-1-0-1 > repeating same pattern, not randomness > > changing maxfanout in synplify will change the erratic behaviour but I > have not managed to get the shift register ever work in case where > FPGA is really full. > > SPI clock is 4MHz (or lower doesn seem to make any difference) > > this time I am giving up, that is not trying to force the shift > register to work, but find solution that works > > the problem only occourcs on Actel FPGA, and yes yes it works in > s=EDmulation it works in xilinx FPGA, etc.. > > Antti > who this time really doesnt know the solution :( So is m_sck actually using global routing, or has it been routed normally? I've seen similar problems when clocks have been routed using local nets. I would suggest forcing m_sck to use a global net, or since your using Actel you could force it on to one of the local global spines. I can't remember how to do it, but I know there is an app note saying what constraints are needed. Neill.Article: 125218
Antti wrote: > but it leaves an un-easy feeling, if the FPGA was working wrong > because of unexplained reason, the same or similar reason could cause > new trouble somewhere else too. Did you check the final results Synplify generated (technology mapping) and if that result was sane. At least Synplify 8.8 was unusable due to many bugs. S 8.6.2 and 8.9 seem to be better in terms of creating working chips. --KimArticle: 125219
On 18 Okt., 09:37, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > Antti wrote: > > but it leaves an un-easy feeling, if the FPGA was working wrong > > because of unexplained reason, the same or similar reason could cause > > new trouble somewhere else too. > > Did you check the final results Synplify generated (technology mapping) > and if that result was sane. At least Synplify 8.8 was unusable due > to many bugs. S 8.6.2 and 8.9 seem to be better in terms of creating > working chips. > > --Kim the failing desing was made with S 8.8A1 and was not tested with other version of synthesis tools after my quiz1 issue, that looked like tool error or faulty FPGA, I was not to belive that another problem so close the first one is related to tools making a mess, so I was very hard trying to find problem in my design. I have made backup of the "known failing with 8.8" design, when i have time, i will retest it with 8.6.2 I did look actel technology view, and did not see anything totally wrong at quick look, but i also did not fully look it over as the signals are hard to follow and thanks a zillion - the suggestion that "8.8 was unusable" it is golden already, it gives hope that the problem is solvable AnttiArticle: 125220
On 18 Okt., 09:37, nei...@pipstechnology.co.uk wrote: > On 17 Oct, 21:44, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > > > Hi ho > > > here is code > > > process (m_sck) begin > > if (m_sck'event and m_sck=3D'1') then > > do64(62 downto 0) <=3D do64(62 downto 0) & M_DI; > > end if; > > end process; > > LEDS <=3D do64s(63 downto 60); > > > M_DI, M_SCK are driven by external MCU SPI interface. > > the MCU send either > > 0x90 00 00 00 00 00 00 00 > > or > > 0x00 00 00 00 00 00 00 00 > > > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1 > > when the FPGA is full, there will blink all off, then 1-1-0-1 > > repeating same pattern, not randomness > > > changing maxfanout in synplify will change the erratic behaviour but I > > have not managed to get the shift register ever work in case where > > FPGA is really full. > > > SPI clock is 4MHz (or lower doesn seem to make any difference) > > > this time I am giving up, that is not trying to force the shift > > register to work, but find solution that works > > > the problem only occourcs on Actel FPGA, and yes yes it works in > > s=EDmulation it works in xilinx FPGA, etc.. > > > Antti > > who this time really doesnt know the solution :( > > So is m_sck actually using global routing, or has it been routed > normally? > > I've seen similar problems when clocks have been routed using local > nets. I would suggest forcing m_sck to use a global net, or since > your using Actel you could force it on to one of the local global > spines. I can't remember how to do it, but I know there is an app > note saying what constraints are needed. > > Neill.- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - with defaul maxfanout of 12 synplify insert some 5 buffer in the M_SCK path global clocks are all used, because of routing constraints some set- reset nets need to be driven by global nets otherise designer will use 2 cells for 1 flip flop, the FPGA is very full so I used the global nets first to optimize for smallest FPGA resource useage. but - global or not, a 64 bit shift register clocked at 4MHz should work in ANY modern FPGA no matter what. there can not be any setup or hold violation. and the same erratic shift was also happening at even lower clock, below 2MHz. and yes I play some more with the global nets, they seem to be a key in Actel technology. AnttiArticle: 125221
i observed that all processes registered with SC_THREAD macro are
called with the same thread. Is this correct?
In my module im having a infinite loop inside the process which reads
from a port attached to sc_signal_in_if, which does not wait but
return immediately. see below : this is the testbench of a UART, which
waits for the start bit. when thread arrives here, it never exit. so
my other processes are never called once the thread enters this
process, because it uses the same thread for all of them.
void data_receive()
{
cout << __FUNCTION__ << " : " << GetCurrentThreadId() << endl;
wait(1, SC_NS);
while(true)
{
if(serial_data_in_port->read() == 0) //start bit
{
// othet statements
}
}
}
Article: 125222Antti wrote: > but - global or not, a 64 bit shift register clocked at 4MHz should > work in ANY modern FPGA no matter what. > there can not be any setup or hold violation. and the same erratic > shift was also happening at even lower clock, below 2MHz. > > and yes I play some more with the global nets, they seem to be a key > in Actel technology. If this is clocked from a uC, one thing you could do, is add a loop readback - where you either simply use the SR as a delay line, and check you get back what left 64 clocks ago, or add a Load option, so you can read back any latched nodes, to verify their content ? -jgArticle: 125223
Hi everyone, pardon me but I'm pretty new to this. I'm using a Spartan 3 right now, and I'm trying to provide source synchronous clock clocking to a SDR SDRAM using DDR register. The component looks something like this: OFDDRCPE sdram0OutputClock ( .Q(sdram0_clk), .C0(sdram_clk), .C1(~sdram_clk), .CE(1'b1), .CLR(1'b0), .D0(1'b1), .D1(1'b0), .PRE(1'b0) ); The input clock is sdram_clk and the output clock to the sdram is sdram0_clk The problem is I'm not sure whether I need to specify any extra constraints in the UCF file for sdram0_clk. Is there anything else to take note of? Are sdram_clk and sdram0_clk considered as different clock domains? If so how do I get the data back to the sdram_clk domain? Thanks in advance, Ben.Article: 125224
Hello all, I would like to ask if i can install in my computer 2 different versions of EDK, one older than the other. O/S : Windows XP regards xenix
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