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
GaLaKtIkUs™ wrote:
> On Mar 23, 8:45 am, "MM" <m...@yahoo.com> wrote:
>> "GaLaKtIkUsT" <taileb.me...@gmail.com> wrote in message
>>
>> news:1174626985.784318.16210@n76g2000hsh.googlegroups.com...
>>
>>
>>
>>> This board INVERTS LVDS PAIRS ie: if I
>>> have an output {XP,XN} I get the input {XN,XP}. ({A,B}=A on P pin and
>>> B on N pin).
>> 1. I doubt anyone can understand your description above. Are you trying to
>> say that the wires are crossed on the board?
>> 2. Use a scope.
>>
>> /Mikhail
>
> They are not crossed like X. the problem is the following if we try
> (using the loop back board) to get P pin on P pin and N pin on N pin
> we will be obliged to cross the wires (make an X on the board). To
> avoid this the guy ho made that loopback board decided to send the P
> to N and N to P and says that the only problem will the inversion of
> the logic levels.
> I reformulate my question in more simple terms:
> I LVDS pins are crossed what would be the result? only inversion of
> logic levels or more?
> Mehdi
1) Are you using 8B10B or some similar coding?
2) use a scope
Article: 117126Paul wrote: > What's with all the xilinx altera rivalry in the world? I mean.. I > can seem THEM being rivals... being competitors and stuff.... but why > US, the users? We'd be far better off if we just picked whatever part > was best for our individual application. At work, I've generally used > xilinx - just because they have best fit the applications I was > looking for. When I'm mucking around with a project at home, Altera > is usually better because I can get much more FPGA in a QFP package > that I stand a chance at soldering by hand. Brand loyalty seems so > silly to me... why? to avoid learning another one of those wildly > difficult tool sets? (psst... I'm joking... neither is too > challenging!) Anywho... does anyone actually have a legitimate > reason for brand loyalty? Or is it just the PC/Mac/Linux crap > rehashed? > > > > On Mar 22, 10:47 am, Austin Lesea <aus...@xilinx.com> wrote: >> Paul, >> >> Thanks for this morning's good laugh. >> >> Wondered where you were hiding. >> >> Welcome back. >> >> Austin Why do Ford owners give Chevy drivers flak?Article: 117127
http://www.fpga4fun.com/10BASE-T0.html "ritesh" <rits.desai@gmail.com> wrote in message news:1174627417.054633.106210@o5g2000hsb.googlegroups.com... > When I am sending some frame from the PC to MAC implemented in the > ML-402 board, It receives the whole frame with proper data, but not > able to calculate FCS properly and generate a error signal for it. > Same thing happen in case of Transmission also. > can anyone suggest how to impletement CRC and generate a FCS, and > in what order we have to send frame to calculate it? >Article: 117128
JK wrote: > Few doubts I would like to get clarified, > > 1. Weather synchronizers are required for control signals only or for > data signals also? If you need to guarantee that all data bits will be valid at the same time as control signals are applied and the control signals do not provide such a guarantee (handshake or other such), you will need to synchronize the data somehow. This is commonly done with asynchronous FIFOs. > 2. Internal to FPGA, suppose 2 different clock domains are there - do > signals crossing from one clock domain > to another need synchronizers? or can we avoid synchronizers by > applying some constraints? > If yes, what are these contraints(in xilinx)? Domain-crossing must be handled by logic, constraints cannot do anything about it. If the two clocks are related by DCM, the synthesis tools are often capable of figuring the constraints out by themselves but this may still require logic if the clock ratios may lead to close cross-domain clock edges. > 3. How can we decide on a false path? suppose one signal is crossing > from one clock domain to another can be > declared as a false path? Yes... but only if momentarily invalid data will not cause a design malfunction. For example, I built a display engine and the registers to configure the display line and column count are routed as false paths between my control bus clock and display engine clocks because the worst-case side-effect is a one-frame display glitch, which is completely insignificant since the display's PLL will need a few seconds to lock on the new timings. > 4. Is it OK to have negative hold time(<1 ns) in timing report? can > we > ignore this timing violation safely? Negative slack indicates that your design failed to meet your timing targets. There is no guarantee that the design will work correctly. Even if it does work on the testbench, it may become unstable with minute variations across devices, supply voltages, aging and operating temperature. > 5. What is the difference between clock jitter & clock skew? > With Xilinx DCMs, I need Clk2x, Clk2x<180, Clk2x<270 & Clk4x. > So, with no other option, I am going for cascaded DCMs. > In this kind of situations, what best we can do to avoid/minimize > clock skew problems? Jitter is a random variation around an average period or offset, it is caused by variations in the transistors' switching characteristics which are themselves caused by numerous factors like electromagnetic noise, supply voltage and temperature. Skew is a constant (in theory) delay mismatch caused primarily by uneven path lengths. Since DCMs add a fair amount of jitter and require low jitter to work properly, it is likely that your cascaded DCM will fail to lock due to compound jitter, you will most likely have to use some other external clock source. I tried cascaded DCMs with V2P a few times but the second DCM never locked on, you may have more luck with the V4.Article: 117129
Hi everybody, I am using XSA-3S1000 v1.0 and XStend v3.0. Tools are Xilinx ISE 8.1i and EDK 8.1i. I created a simple project in EDK. Then I downloaded x_download.bit. If I used XSA-3S1000 board standalone, so iMPACT worked well. But when I used both XSA-3S1000 and XStend board, iMPACT always showed an error: "An error appears in the status register; the CRC Error bit is NOT 0." and failed to program. Anybody please tell me why ? or any suggestion. Thanks in advance, ToanArticle: 117130
Hans, I was informed by the software group that the information on the website was outdated, and they needed to update it. They replied, saving me the effort. If anything, the software folks are delighted I review this board, and let them know about issues (saves them a lot of time). I do a lot of reading for Xilinx. Since I read at faster than 2500 wpm, it is nothing for me to read the entire Cyclone 3 handbook, user's guide, white papers and app notes. Takes me about 30 minutes. With almost total recall, I can then help others write white papers, and offer up my opinions. As opposed to our competition, we were not all required to take empathy and sensitivity training classes (Business Week article*) -- we have a code of conduct that places respect for others at the highest level. "Nice," however is not one of our values. Being nice is my choice, but should never get in the way of being honest. Austin * http://www.businessweek.com/magazine/content/06_27/b3991084.htmArticle: 117131
Dmitry Teytelman wrote: > On Wed, 21 Mar 2007, Duane Clark wrote: > >> dimtey@moc.liamg wrote: >>> ... So here is the problem: the data is written correctly into >>> the SRAM, but not into the block RAM. It is a timing problem - >>> errors go away if I lower the clock frequency. ... >> Show the actual clock constraints you are using. > > The data acquisition logic and BRAMs are clocked by a DCM driving a > BUFG. The DCM divides the input clock by 2 (using CLKDV output). Here > is the timing constraint on the DCM input clock: > > NET "clkp" TNM_NET = FFS(*) "clkp"; TIMESPEC "TS_clkp" = PERIOD > "clkp" 3.8 ns HIGH 50 %; > Let me step back from the long thread a moment. According to the constraints guide: Assigning Definitions for DLL/DCM Clocks TRANSLATION (NGDBuild) propagates TNM_NET tags through DLLs and DCMs. NGDBuild creates new TNM_NETs for each of the DLL and DCM output taps and associated PERIOD statements. The code takes into account the phase relationship factor of the outputs for the DLL, and also performs the appropriate multiplication or division of the PERIOD value. The code also takes into account any of the PHASE taps adjustments. This means that for OFFSETs and cross-clock domain paths, the timing tools now know the relationship for PHASE shifts also. So have you tried just a period constraint on the input clock and removed all other constraints?Article: 117132
Duane Clark wrote: > Dmitry Teytelman wrote: >> On Wed, 21 Mar 2007, Duane Clark wrote: >> >>> dimtey@moc.liamg wrote: >>>> ... So here is the problem: the data is written correctly into >>>> the SRAM, but not into the block RAM. It is a timing problem - >>>> errors go away if I lower the clock frequency. ... >>> Show the actual clock constraints you are using. >> The data acquisition logic and BRAMs are clocked by a DCM driving a >> BUFG. The DCM divides the input clock by 2 (using CLKDV output). Here >> is the timing constraint on the DCM input clock: >> >> NET "clkp" TNM_NET = FFS(*) "clkp"; TIMESPEC "TS_clkp" = PERIOD >> "clkp" 3.8 ns HIGH 50 %; >> > > Let me step back from the long thread a moment. According to the > constraints guide: Ugg... never mind. I see you did say this was the input clock.Article: 117133
On Mar 22, 5:53 pm, mwiesb...@gmail.com wrote: > Here are a few more details about the project of getting this core up > and running: > > Using the GMII Interface, in trimode > I am trying to keep this project inside of ISE , and not use EDK for > anything at the moment. > The only changed I made to the UCF so far would be the LOC assignments > of the RX/TX Signals and with the IDELAYCTRL location. I am still > looking more into the IDELAYCTRL location that I should be using since > this part is still pretty new to me and I haven't done much work with > constraints past basic pin assignment. > > As well, if anyone know any good sites that go over the constraints > used in these UCF files, please let me know. I do already know about > Xilinx's scattered PDF files on their site which for me at least do > not always tend to be that clear, so anything other than those (such > as some .edu site with lab handouts, etc) would be great! > > Thanks again, > -Mark > > On Mar 22, 5:31 pm, mwiesb...@gmail.com wrote: > > > Hello, > > > I am trying to get the Virtex-4 Ethernet MAC Wrapper IP Core up and > > running on my Avnet Virtex-4 FX12 Mini Module (http://tinyurl.com/ > > yqc6ah), and I am having all sorts of problems. One of the main > > problems right now seems to be my understanding of the UCF file and > > what to edit or not to edit, since the rest of the design should be > > already set up fine from what I have read in the user guide. > > > I am trying to run the example design that was generated,so that I may > > send the board a packet and it send me one back to make sure > > everything is working correctly, but so far no luck. > > > Has anyone used this ip core before with some successes , no matter > > what version? Please let me know if so... it would be greatly > > appreciated! > > > -Mark > > (I can post or upload as many details/files as requested, but I didnt > > want to just spam all that stuff up here on the first post) I have used the Coregen TEMAC core in several designs. The generated files include the LOC for IDELAYCTRL in the source code, so I would recommend you remove that first. .e.g. my vhdl wrapper temac_v3_2_block.vhd has the line below. You can either comment it out or remove it completely. attribute loc of dlyctrl : label is "IDELAYCTRL_X2Y1"; If you don't care about the IDELAYCTRL replication, you don't even LOC it in UCF. If you really want to know which pins are associated with which IDELAYCTRL, you can use ADEPT to view that (http:// home.comcast.net/~jimwu88/tools/adept/): load the device and click View->Show IDELAYCTRL). The other thing you may need to play with is the delay on gmii_rx_clk. You can change it (IOBDELAY_VALUE of IDELAY block) either in source code (rx_clk_gen.v/vhd) or in UCF. HTH, JimArticle: 117134
Has anybody ever used the Amphion CS6651 Cores targeted for either Xilinx or Altera FPGAs? I am currently using the Video core on an Altera Stratix FPGA and I am having trouble getting the core to function. I have set the clock rate to 27mhz, along with the external frame store as well. I am using the core as a free running decoder, only setting up the 1us clock divisor register to 32'd0000001B (decimal 27 for the 27mhz clock source).Article: 117135
Austin Lesea wrote: > The only problem I have is that once you see how much 65nm varies due to > process (on the same die, let alone the same wafer), 'typical' ends up > being pretty meaningless. So if we could probe inside a recent FPGA, we would have a real chance of seeing a noticeable speed difference across the die? Any idea what the percentage would be? I suppose it could be checked by building ring oscillators at various locations.Article: 117136
On Mar 23, 6:26 am, John_H <newsgr...@johnhandwork.com> wrote: > Paul wrote: > > What's with all the xilinx altera rivalry in the world? I mean.. I > > can seem THEM being rivals... being competitors and stuff.... but why > > US, the users? We'd be far better off if we just picked whatever part > > was best for our individual application. At work, I've generally used > > xilinx - just because they have best fit the applications I was > > looking for. When I'm mucking around with a project at home, Altera > > is usually better because I can get much more FPGA in a QFP package > > that I stand a chance at soldering by hand. Brand loyalty seems so > > silly to me... why? to avoid learning another one of those wildly > > difficult tool sets? (psst... I'm joking... neither is too > > challenging!) Anywho... does anyone actually have a legitimate > > reason for brand loyalty? Or is it just the PC/Mac/Linux crap > > rehashed? > > > On Mar 22, 10:47 am, Austin Lesea <aus...@xilinx.com> wrote: > >> Paul, > > >> Thanks for this morning's good laugh. > > >> Wondered where you were hiding. > > >> Welcome back. > > >> Austin > > Why do Ford owners give Chevy drivers flak? Us Honda drivers laugh at both. -aArticle: 117137
On Mar 20, 9:09 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> wrote: > I really wish Xilinx would put more effort in making their synthesis > tool-chain more stable before reworking GUIs and adding more features. > Until then, Synplify is still an option (perhaps more along the lines of > necessary) for more serious projects. Synplify and Precision are options only if the budget allows. At my previous job, we used Precision because we used Brand A, Brand L and Brand X parts. Now I do only Brand X because the volumes are low (and we like the PPC cores). A Precision license is a substantial cost, and XST seems to do what we need (in spite of its annoyances). -aArticle: 117138
The schematic flow is slightly more than maintenance mode. I would call it minimal improvement mode with most effort focused on quality. Steve "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:46031907$1@clear.net.nz... > > Thanks. I should have queries Schematic flow as well ? > as some still use that (see another thread..) - is that in maintenance > mode as well ? > > Of course, maintenance mode can be a good thing, because it > means the code-base is very stable, with no surprises lurking in the next > updates.... :) > > -jg >Article: 117139
Post your system.mhs file... /Mikhail "Sandip" <sandip.gaikwad@gmail.com> wrote in message news:1174651444.673365.68820@y66g2000hsf.googlegroups.com... > Hi, > > I have attached my custom IP to the OPB bus. The Custom IP contains > ports which should directly interact with the outside world. I have > ML403 board. I want to connect these ports to these GPIOs. So I edited > the system.ucf file to contain these ports and with oppropriate GPIO > names. Generation Netlist was successfull. But it gave error during > bitstream generation. The errors specified that the nets that put in > the system.ucf file was unable to recognise. > > Can anyone help me in connecting the custom IP ports to the GPIO pins. > > Thanks and regards, > Sandip >Article: 117140
Tim, This is something one has to do in order to know just how "bad" the timing can get. Obviously, one has to specify the worst possible timing in order to have a design that works. If one logic block (let us be generic here) is slow, and it is slower than what you thought it was going to be when you made your speeds file, then that chip might fail to meet timing on that path, and you get data errors. How you go about finding the worst of the worst on a die is something that we have to do, so that we can be sure we are OK when we ship the part to the customer. A ring oscillator is a very useful thing to do this, as measuring frequencies is often easier than measuring delays. There are other ways to do this, also. Whatever, we have to do this in such a way to meet the quality objectives, and the cost of testing objectives at the same time. This is yet another reason why Easypath(tm) devices can be much lower in cost: we only need to test the paths you use to meet timing, not every possible path. It is also a reason why ASICs (structured, or otherwise) might have very poor yields all of the sudden (known as a 'yield crash' in the business)! If your ASIC has a yield crash, you may only be affected because your supply of chips disappears, but if you are paying for the wafers, then you will be doubly punished. There are papers on this subject (search IEEE, etc.) as well as papers yet to be published on the subject. This is one more reason why using a FPGA device takes a lot of the work out of what you would have to do otherwise with an ASIC: we do the hard work so you don't have to. We also remove substantial risk (yield, performance-timing closure, latchup, single effect upsets, etc.). Every one of the risks above is documented fact for some structured ASIC suppliers. That means each one has already happened to at least one customer! This is one of the reasons why the structured ASIC business has more companies that have tried it and left, than those that are still struggling to make a go of it. Don't forget that Xilinx, too, was once a 'structured ASIC supplier' (HardWire(tm) devices). Been there, done that, learned our lesson. And yes, as things have gotten smaller, the variation has reared its ugly head. Learning to live with the variation, or prevent it in the structures that you care about is no easy thing to do. Identically drawn devices, next to each other, can vary by +/- 20% in some cases. Try using devices like that to match something at all! The good news is that we IC designers "have ways" to meet our objectives. AustinArticle: 117141
On Mar 23, 4:02 pm, "Bob Golenda" <bgoli...@nospam.net> wrote: > Hi Zoltan, > > > I've done it! You don't have to implement the whole xsvfplayer. > > Youi've done exactly what? Written a stand alone JTAG programmer that > programs the XCF part without using any XSVF files or XSVFPlayer etc. stuff? > > > If you want to support only xcf devices in a fixed environment, the > > programming is fairly simple. > > Sure, but it's knowing what you need to do, and the timing that is the > hardest part, since there is no spec for programming the XCF. Yes, without xsvf player. We have very limited resources in our uC, so I have to program the XCF page by page (512 bytes). I've just wrote the code to implement the JTAG programming protocol to program one page on XCF and then stream the mcs file page by page to the uC and it programs the flash. >>there is no spec for programming the XCF You can find some open-source xcf programming tools using the parallel port pins to program a xcf device like a JTAG programmer. You can strip down those tools to the bare minimum. You can find a conservative JTAG clock freq, so you should'nt worry about timing. ZoltanArticle: 117142
Hi, Have anyone heard anything on Xilinx on Solaris 10 and AMD? /michaelArticle: 117143
On Mar 19, 4:41 pm, "Bob Golenda" <bgoli...@nospam.net> wrote:
> Thank you very much for that pointer. It still appears that aside from what
> Antti did, no one (at least on this list) has successfully done a real JTAG
> programmer for the XCF...just XSVF Player type programmers. I just find
> that odd.
>
> "MM" <m...@yahoo.com> wrote in message
>
> news:5684abF27jrufU1@mid.individual.net...
>
> > Take a look at this old discussion:
> >http://tinyurl.com/277l9a
>
> > /Mikhail
Stop whining and here is the code! But please don't ask for more help.
Figure out the rest on your own!
#define BITS(v, b) (v) |= (1 << (b))
#define BITC(v, b) (v) &= ~(1 << (b))
#define BITSC(v, b, s) do { if (s) BITS(v, b); else BITC(v,
b); } while (0)
#define BITN(v, b) (v) ^= (1 << (b))
#define ISBIT(v, b) ((v) & (1 << (b)))
#define JTAG_ALL_ZEROS NULL
#define JTAG_ALL_ONES (void*)-1
#define XCF_IR_LENGTH 8
#define XCF_SERASE 0x0A
#define XCF_ISPEN 0xE8
#define XCF_FPGM 0xEA
#define XCF_FADDR 0xEB
#define XCF_FERASE 0xEC
#define XCF_FDATA0 0xED
#define XCF_CONFIG 0xEE
#define XCF_FVFY0 0xEF
#define XCF_FVFY1 0xF8
#define XCF_NORMRST 0xF0
#define XCF_USERCODE 0xFD
#define XCF_IDCODE 0xFE
#define XCF_BYPASS 0xFF
// This specifies the XCF location
// In this example there is S3-1000 device in fron of the XCF04s
#define XCF_HIR_LENGTH 6
#define XCF_TIR_LENGTH 0
#define XCF_HDR_LENGTH 1
#define XCF_TDR_LENGTH 0
#define jtag_tms(b) BITSC(PORTC, PINC6, b)
#define jtag_tdi(b) BITSC(PORTC, PINC5, b)
#define jtag_tck(b) BITSC(PORTC, PINC3, b)
#define jtag_tdo() ISBIT(PINC, PINC4)
void jtag_tck_cycle(int count)
{
while (count--)
{
jtag_tck(1);
jtag_tck(0);
}
}
void jtag_tms_transition(unsigned int tms, int count)
{
while (count--)
{
jtag_tms(tms & 1);
jtag_tck_cycle(1);
tms >>= 1;
}
}
#define jtag_reset_tap_state() jtag_tms_transition(0x1F, 5)
#define jtag_reset_idle_tap_state() jtag_tms_transition(0x1F, 6)
void jtag_shift(u8* ptdi, u8* ptdo, int num_bits, int last)
{
u8 tdi_byte, tdo_byte;
int i;
while (num_bits)
{
// Process on a byte-basis, LSB bytes and bits first
if (ptdi == JTAG_ALL_ZEROS)
// All zeros
tdi_byte = 0;
else
if (ptdi == JTAG_ALL_ONES)
tdi_byte = 0xFF;
else
tdi_byte = *ptdi++;
tdo_byte = 0;
for (i = 0; (num_bits && (i < 8)); i++)
{
num_bits--;
if (last && !num_bits)
// Exit Shift-DR state
jtag_tms(1);
// Set the new TDI value
jtag_tdi(tdi_byte & 1);
tdi_byte >>= 1;
// Save TDO bit
if (ptdo && jtag_tdo())
tdo_byte |= 1 << i;
// Pulse TCK
jtag_tck_cycle(1);
}
// Save TDO byte
if (ptdo)
*ptdo++ = tdo_byte;
}
}
int jtag_shift_r(
unsigned int tms, int tms_count,
u8* hdr, int hdr_count,
u8* tdi, u8* tdo, int count,
u8* trl, int trl_count,
int last)
{
if (tms_count)
jtag_tms_transition(tms, tms_count);
// Shift header
if (hdr_count)
jtag_shift(hdr, NULL, hdr_count, 0);
// Shift TDI/TDO
if (count)
jtag_shift(tdi, tdo, count, trl_count == 0 && last);
// Shift trailer
if (trl_count)
jtag_shift(trl, NULL, trl_count, 1);
if (last)
// Update TAP state: Exit->Idle
jtag_tms_transition(1, 2);
return 0;
}
int jtag_shift_dr(u8* ptdi, u8* ptdo, int num_bits)
{
return jtag_shift_r(
1, 3, // TMS transition: Idle->Shift DR
JTAG_ALL_ZEROS, XCF_HDR_LENGTH,
ptdi, ptdo, num_bits,
JTAG_ALL_ZEROS, XCF_TDR_LENGTH,
1);
}
int jtag_shift_ir(u8 op)
{
return jtag_shift_r(
3, 4, // TMS transition: Idle->Shift IR
JTAG_ALL_ONES, XCF_HIR_LENGTH,
&op, NULL, XCF_IR_LENGTH,
JTAG_ALL_ONES, XCF_TIR_LENGTH,
1);
}
int xcf_erase(void)
{
u16 d16;
int i;
jtag_reset_idle_tap_state();
jtag_shift_ir(XCF_BYPASS);
jtag_shift_ir(XCF_ISPEN);
jtag_shift_ir(XCF_FADDR);
d16 = 1;
jtag_shift_dr((u8*)&d16, NULL, 16);
jtag_tck_cycle(2);
jtag_shift_ir(XCF_FERASE);
for (i = 0; i < 2400; i++)
jtag_tck_cycle(1000);
jtag_shift_ir(XCF_BYPASS);
jtag_reset_idle_tap_state();
return 0;
}
int xcf_program_start(int write)
{
u8 d8;
jtag_reset_idle_tap_state();
jtag_shift_ir(XCF_ISPEN);
if (write)
{
d8 = 0x34;
jtag_shift_dr(&d8, NULL, 6);
}
return 0;
}
int xcf_program_end(void)
{
jtag_shift_ir(XCF_BYPASS);
jtag_reset_idle_tap_state();
return 0;
}
int xcf_program_write_row(u16 row, u8* data)
{
u16 addr = (u16)(row * 0x20);
jtag_shift_ir(XCF_FDATA0);
jtag_shift_dr(data, NULL, 8*AVRB_XCF_SIZE_OF_PAGE);
jtag_tck_cycle(2);
jtag_shift_ir(XCF_FADDR);
jtag_shift_dr((u8*)&addr, NULL, 16);
jtag_tck_cycle(2);
jtag_shift_ir(XCF_FPGM);
jtag_tck_cycle(14000);
return 0;
}
Article: 117144Hi Zoltan, > I've done it! You don't have to implement the whole xsvfplayer. Youi've done exactly what? Written a stand alone JTAG programmer that programs the XCF part without using any XSVF files or XSVFPlayer etc. stuff? > If you want to support only xcf devices in a fixed environment, the > programming is fairly simple. Sure, but it's knowing what you need to do, and the timing that is the hardest part, since there is no spec for programming the XCF.Article: 117145
morpheus wrote: > ... I was > wondering how I should truncate/round. Do I have to convert since the > data is already in 2's complement format and if I just > truncated....can I just use the upper bits of the lpf output as the > input to the CORDIC? Just using the upper bit will give you a bit of DC offset - rounding always goes down to -inf (so, not closer to 0). Rounding towards the next even (or odd) number (also known as Banker's rounding) seems to be an accepted method. You could of course add a bit of phase distortion but keep the total spectral energy intact by truncating and remembering the ~1/2 LSB bit you just threw away and adding that to the next sample before truncating again. I never tried it and would be interested in the result. Best regards, BenArticle: 117146
On Mar 23, 7:09 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> wrote: > JK wrote: > > Few doubts I would like to get clarified, > > > 1. Weather synchronizers are required for control signals only or for > > data signals also? > > If you need to guarantee that all data bits will be valid at the same time > as control signals are applied and the control signals do not provide such > a guarantee (handshake or other such), you will need to synchronize the > data somehow. This is commonly done with asynchronous FIFOs. > > > 2. Internal to FPGA, suppose 2 different clock domains are there - do > > signals crossing from one clock domain > > to another need synchronizers? or can we avoid synchronizers by > > applying some constraints? > > If yes, what are these contraints(in xilinx)? > > Domain-crossing must be handled by logic, constraints cannot do anything > about it. If the two clocks are related by DCM, the synthesis tools are > often capable of figuring the constraints out by themselves but this may > still require logic if the clock ratios may lead to close cross-domain > clock edges. > > > 3. How can we decide on a false path? suppose one signal is crossing > > from one clock domain to another can be > > declared as a false path? > > Yes... but only if momentarily invalid data will not cause a design > malfunction. For example, I built a display engine and the registers to > configure the display line and column count are routed as false paths > between my control bus clock and display engine clocks because the > worst-case side-effect is a one-frame display glitch, which is completely > insignificant since the display's PLL will need a few seconds to lock on > the new timings. > > > 4. Is it OK to have negative hold time(<1 ns) in timing report? can > > we > > ignore this timing violation safely? > > Negative slack indicates that your design failed to meet your timing > targets. There is no guarantee that the design will work correctly. Even if > it does work on the testbench, it may become unstable with minute > variations across devices, supply voltages, aging and operating temperature. > > > 5. What is the difference between clock jitter & clock skew? > > With Xilinx DCMs, I need Clk2x, Clk2x<180, Clk2x<270 & Clk4x. > > So, with no other option, I am going for cascaded DCMs. > > In this kind of situations, what best we can do to avoid/minimize > > clock skew problems? > > Jitter is a random variation around an average period or offset, it is > caused by variations in the transistors' switching characteristics which > are themselves caused by numerous factors like electromagnetic noise, > supply voltage and temperature. Skew is a constant (in theory) delay > mismatch caused primarily by uneven path lengths. > > Since DCMs add a fair amount of jitter and require low jitter to work > properly, it is likely that your cascaded DCM will fail to lock due to > compound jitter, you will most likely have to use some other external clock > source. I tried cascaded DCMs with V2P a few times but the second DCM never > locked on, you may have more luck with the V4. Thnaks Daniel, Thank you very much. Regards, JKArticle: 117147
steve.lass@xilinx.com wrote: > The schematic flow is slightly more than maintenance mode. > I would call it minimal improvement mode with most effort focused > on quality. > > Steve > > "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message > news:46031907$1@clear.net.nz... > >>Thanks. I should have queries Schematic flow as well ? >>as some still use that (see another thread..) - is that in maintenance >>mode as well ? >> >>Of course, maintenance mode can be a good thing, because it >>means the code-base is very stable, with no surprises lurking in the next >>updates.... :) >> >>-jg >> > > > There is no particular need for improvements but there is a big need to fix it. The schematic flow is totally broken in versions 8.1, 8.2 and 9.1. 8.1 would not import a version 7 project. 8.2 had such a bad memory leak that it would not make it through xst. 9.1 showed no improvement. Your support people sent a fix for part of the memory leak but that showed two more fatal bugs. The ucf file pin assignments get used on submodules and so it thinks there is an error and, if you remove the ucf file to try to go on, it cannot find the libraries and quits. It does however, destroy the project file in the process. I plan on converting these to vhdl but it would be nice to be able to do it in an incremental manner.Article: 117148
Herbert Kleebauer wrote: > Sorry, but it really doesn't matter whether the AND gate is implemented > as AND gate, by multiplexers or as a look-up table. They have learned > that this all is equivalent and that the order of complexity is the > same. But they must learn that there is big difference in the complexity > for the ALU operation "add" and "div" and they don't see this in > the VHDL source code. In VHDL, you are correct, but in Boolean Eqn entry [CUPL], you have to manually 'build' the adder, so they are VERY much aware of the cost. You can also see the ALU resource any time you glance at the report file. You can even discuss the trade-offs in adders, with speed/width, if you want to, simply by letting the tools remove nodes, or not. [try doing that in the SCH pathway ?] -jgArticle: 117149
Herbert Kleebauer wrote: (snip) > These are not electrical engineering but computer science students. > Their job will be to design software and not hardware systems. But > in order to do a proper software design, you need to understand the > principles of the underlying hardware so you get a feeling what a > few lines of HL code can mean for the hardware. > I don't know if all the supporters of VHDL/Verilog/HandleC here have > done low level logic development using a graphical representation and > just don't recognize how important that is to become a good designer > at VHDL level or if they have never done this and still think they > are good developers because the VHDL compiler is good enough and > therefore they don't need to know anything about lower levels. To me the question isn't graphical vs. textual, it is how well one understands the underlying logic. > Again the city map is a good example: If you want to drive from > A to B, you call a taxi, the driver enters the target into the > navigation system and this system mostly does a much better job > you could do with the city map on your lap. So this is the best > you can do if you know nothing about the city. But if you know > the layout of the city and you know that there is a river with > only two bridges where you have to wait a long time because of > the high traffic and you also know that there is a small bridge > which could only be passed by foot, then you could do a much > better job by driving to the small bridge, cross the river by foot > and use an other taxi on the other side. I agree with this one. Though a good navigation system might know about the bridge. Some city bus systems have a computer which will do route calculations. That might include walking across a bridge, otherwise it is up to the user to do that before calling the taxi. > The same is true for software: if you know how the hardware > works you maybe can choose a different approach to solve the > problem which is much more appropriate for the hardware. The > compiler can do local optimizations extremely good, but the > best global strategy has to be chosen by the programmer. > And I think the same is true for hardware design. Just writing > down VHDL statements without understanding the consequences > for the generated hardware is not the way to go. I completely agree with this statement. One thing one must learn, either with VHDL or graphical entry is the cost for each logic block. Just as in C programming, the tools don't help much, one just has to learn it. > The purpose of Universities is not to teach the students the > use of tools but to teach them how to recognize, analyze and > solve problems. The tools you use to solve the problems change > rapidly but the ability to understand the source of a problem > and analyze it from all angeles without using blinders is an > essential requirement for the whole life. I 100% agree here. (Though I know a lot of people don't.) > And as I said in the original posting, replacing the schematic > entry by VHDL/Verilg isn't an alternative. All I wanted to know > is, if somebody already was able to run the old Vielogic (DOS) > on an actual OS (using a virtual machine). Or, whether there > exists new FPGA's with a development system which is as easy > to use as Viewlogic/DOS _AND_ where the chips are available > in a package which could be soldered with a normal soldering > iron on a self made non-multilayer PCP. I think there are > both things available, but I didn't find the _AND_ combination. In different discussions I have suggested that people should remember the days of wiring up TTL gates on breadboards. Using lower level HDL constructions is closer to that than some higher level ones. I don't know about VHDL, but you can do verilog at the gate level. That is, in addition to behavioral and structural there is a level with references to gate level primitives. (snip) > Sorry, but it really doesn't matter whether the AND gate is implemented > as AND gate, by multiplexers or as a look-up table. They have learned > that this all is equivalent and that the order of complexity is the > same. But they must learn that there is big difference in the complexity > for the ALU operation "add" and "div" and they don't see this in > the VHDL source code. Thinks may have changed, last I knew the synthesis tools wouldn't synthesize divide, at least not divide by a variable. Maybe it is just how much I hate using schematic entry tools. If you draw the design on paper using a gate template, maybe using 7400 series logic blocks, and then write the corresponding HDL I don't think you are missing out on anything. I can probably do it with a minimal hand drawn schematic, as I can solve algebraic equations without doing all the intermediate steps, but it does still help to write some down on paper. -- glen
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