Timeline for Verilog Vivado UART design : implementation / bitstream issues
Current License: CC BY-SA 3.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 10, 2022 at 17:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Dec 11, 2021 at 1:05 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Aug 8, 2021 at 17:03 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Apr 10, 2021 at 16:42 | comment | added | Matt | Since you're doing this work for a company, your best bet is to ask a more senior employee. Unless you're the only hardware engineer there, or nobody knows verilog, then you should ask for help. I once had a job where I didn't ask for help much and it didn't go well. Since that job I've asked as much as possible and in the process learned a few things and also discovered problems in the design (if the 3rd explanation still doesn't make sense, it's probably because the plan is wrong). Also, your company probably doesn't want its code posted online, be careful. | |
| Apr 10, 2021 at 12:03 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Nov 29, 2020 at 11:05 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Apr 2, 2018 at 0:05 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Feb 26, 2018 at 4:35 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Jan 24, 2018 at 19:56 | comment | added | stanri |
@MicheleMarconi If you're new to HDL programming in general, I HIGHLY recommend only coding clocked processes with nonblocking statements (that is, only ever using always @(clk) begin... end always blocks, and only using <= in them). For combinatorial logic, only use assign statements. I spent the first year of my HDL coding experience like this because it was how I was taught by my employer and it saved me a LOT of headaches as a beginner.
|
|
| Jan 24, 2018 at 16:21 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Oct 3, 2017 at 6:30 | answer | added | Michele Marconi | timeline score: 0 | |
| Oct 3, 2017 at 6:24 | comment | added | Michele Marconi | @jalalipop That's a possible issue. By going over my post-implementation timing simulation, I noticed that the mem is not being initialized correctly, so what my transmitter is sending is not being perceived as incorrect, but just the result of incorrect initialization of its memory. Now I am onto determining whether it is received incorrectly, saved incorrectly, or the result of some impurities in terms of my logic (increments/decrements of indexes as said in the following comment about Always block, etcetc) | |
| Oct 3, 2017 at 2:03 | answer | added | Greg | timeline score: 1 | |
| Oct 2, 2017 at 13:21 | comment | added | jalalipop | @MicheleMarconi Are you 100% sure the waveforms you're seeing in sim are what you want? The way you describe your issue (first char is correct, followed by garbage) it almost seems like your data frames are getting jumbled. This could happen if you aren't properly sending stop->start bits; I'd check if this is the case but I don't see where your actual clock-by-clock Tx logic is in the code. Try scoping the actual Tx line and comparing it to what you see in simulation. If they are the same, it's possible what you think is correct is actually incorrect. | |
| Oct 2, 2017 at 8:20 | comment | added | Michele Marconi | @jalalipop i also feel like it should be something timing related. The system works 100% the same (to the point of exact clock cycles and waveforms) in post-synth and post-implementation, but while on the FPGA it transmits strange and unrecognizable chars | |
| Oct 2, 2017 at 8:20 | comment | added | Michele Marconi | @Greg coming from VHDL i still have trouble on nonblocking vs blocking: which of the blocks should be absolutely changed to nonblocking? | |
| Sep 30, 2017 at 8:33 | comment | added | Greg |
FYI, your mem array are inferred level-sensitive latches, that is likely unintentional. There is sequential logic still using blocking statements that should be changed to non-blocking; refresher reference.
|
|
| Sep 29, 2017 at 16:48 | comment | added | jalalipop | You will probably have more luck learning to debug in ISIM than hoping someone here will read through your entire code. You know what you expect the state machine to do better than anyone, so it might be immediately obvious just from looking at the waveforms what's going wrong. If it works in simulation, you probably have a timing issue. Also, as an aside, are you synchronizing your RxD line at ahigher level with cascaded flipflops to avoid metastability? That's not relevant right now since you're loopbacking but is important in any asynchronous interface. | |
| Sep 29, 2017 at 8:45 | review | First posts | |||
| Sep 29, 2017 at 8:54 | |||||
| Sep 29, 2017 at 8:45 | history | asked | Michele Marconi | CC BY-SA 3.0 |