asmi

<duplicate>

That's the essence of the question - how do you find out what that "known" frequency is if you're designing a component which is meant to connect to external clock which you have no control over?

He's not talking about that, but rather he wants to know the frequency connected clock is running at synthesis time. This is often needed to calculate a timebase if you have some logic which is supposed to work with real time as opposed to number of cycles. Think of DDR3 refresh for example - you are supposed to do it every X us, so you will need to calculate at synthesis time how many clock cycles that is - because as you know, the logic itself has no concept of time and can only count clock cycles. Unfortunately, there is no such way in generic Verilog/SystemVerilog to know the f

If you want to have any success in FPGA design space, you will need to love reading. In this case, UG471 has everything you need to know. Specifically, it says this: TMDS belongs to the family of physical standards which are driven by the current as opposed to voltage level as previous ones did. This has a number of important advantages for high-speed communications, but it also requires a complete circuit to actually see the data. Different standards approach this in a different way - some require termination to Vcc, some - to ground, yet some - to a midpoint or some other refere

One thing I remember when using SERDES is that they require a proper reset procedure before they are functional. So try adding a reset block (you can use "Processor Reset Block" to sync incoming async reset to the system frequency if you don't feel like doing so HDL) and connecting it to a reset inputs of your SERDES blocks.

He's probably talking about academic discounts, not license vouchers.

No idea.

It's in stock at Digikey right now.

Bytes swapping is allowed as long as it's done to entire byte groups (meaning all lines, DQ, DQS and DM). If you look closely, you will see that entire byte 0 of DDR memory chip is wired to byte 1 on Zynq, and vice versa. Bit swapping within byte is also allowed.

Can you try adding weak pullup resistors (10K) to TCK and TMS lines as recommended by the spec? I actually have pullups for all 4 JTAG signals on my designs, and I never had an issue you're describing.

CC pins are only relevant for inputs AFAIK. Besides E15/E16 are actually CC pins. TMDS uses current driver, so it can't work without termination.

It could be the same problem I had on my Genesys 2 board, as both seem to use the same PHY chip. Symptoms are identical to mine when I checked it for the last time. I was proposed a solution, but I didn't try it yet because I was occupied by other projects: You might want to give it a try to see if it works for you. Though if I my memory serves me, there are separate source files for Zynq's ARM PS and for Microblaze CPUs, even though their contents are for the most part identical.

This is really odd issue. HDMI is only supposed to provide 50 mA of current on it's +5V rail, there is no way it will be enough to power the board. In the schematics, I noticed there is a fuse oddly enough marked R134. I would try desoldering it and replacing with Schottky diode to block reverse current from flowing into the board to see if that solved the issue.

Those settings are incorrect BTW. Specifically, this file has VccAuxIO of 1.8 V while in reality it's 2.0 V, the clock period is also only 2500 ps (or 400 MHz), the board's user guide recommends 1112 ps (899.28 MHz). Clock period of 1111 ps (900.09 MHz) works best in practice though, because it allows setting input clock to exactly 200 MHz, which is what's present on the board. I get that this board is designed for people who know their way around schematics, but still - I think both MIG project file and the user guide needs to be updated. I know that we're talking about only 1 picosecond of d

Memory Interface Generator, Xilinx tool/IP to generate memory controller.