OpenCores
URL https://opencores.org/ocsvn/raytrac/raytrac/trunk

Subversion Repositories raytrac

[/] [raytrac/] [branches/] [fp_sgdma/] [ap_n_dpc.vhd] - Rev 257

Rev

Details | Compare with Previous | Blame

Filtering Options

Clear current filter

Rev Log message Author Age Path
257 Some connections needed to make sign switcheroo works jguarin2002 4186d 22h /raytrac/branches/fp_sgdma/ap_n_dpc.vhd
256 Sign switcheroo added: a tweek to calculate the distance from observer to sphere impact point jguarin2002 4186d 22h /raytrac/branches/fp_sgdma/ap_n_dpc.vhd
248 Corrected an error on the normal jguarin2002 4219d 23h /raytrac/branches/fp_sgdma/ap_n_dpc.vhd
242 AS1 produced an unnoticed delay, the compiler geenerated an extra stage..... so a delay constant was added to sync this extra stage with the operation via ssync_chain jguarin2002 4242d 20h /raytrac/branches/fp_sgdma/ap_n_dpc.vhd
236 Tunnning delay added to q0 queue jguarin2002 4244d 01h /raytrac/branches/fp_sgdma/ap_n_dpc.vhd
235 Tunnning delay added to q0 queue jguarin2002 4244d 01h /raytrac/branches/fp_sgdma/ap_n_dpc.vhd
230 RC 1.0 Previous rev(228), is functional and even more than this one, but is bigger and is for debugging jguarin2002 4250d 04h /raytrac/branches/fp_sgdma/ap_n_dpc.vhd
229 Total RtEngine Hardware, BUT, problems with interconnection... perhaps theres a problem with long path on ssumando5 jguarin2002 4251d 04h /raytrac/branches/fp_sgdma/ap_n_dpc.vhd
228 Fixed a BUG where big differences betweeen exponents difference suffered from miss-signedness because of the width of the result was 1 bit narrower, and still its highest significant bit was taken as the sign, in result big differences in where taken as negative results... leading to situations like A+0=0 cause the exponent chosen as the big one was the zero's (-127) leading to an unexpected 0 in the result. The bug was fixed by correcting the signedness of the operation and making the result less narrower in one bit. jguarin2002 4252d 21h /raytrac/branches/fp_sgdma/ap_n_dpc.vhd
220 ap_n_dpc.vhd es el RTL que integra DataPathControl y ArithPipeLine jguarin2002 4262d 12h /raytrac/branches/fp_sgdma/ap_n_dpc.vhd
219 RayTrac: Non tested and witouh TSE jguarin2002 4262d 14h /raytrac/branches/fp_sgdma/dpc.vhd
212 DPC changes\n\n\t+ established the DCS system rather than the UCA definitively\n\t+ Rather than usign 4 result queues now theres just a single one, of course 4 times wider, this was made to gain simplicity when writing and reading the RTL description that adapts this 4/3/1 word wide result buffer output into a 1 word wide result buffer input\n\t+ Added the Q1 queue to syncrhonize magnitude and normalization ops, managing them to enter at the sime tame rather than different times, formerly it was implemented by setting the normalization and magnitude results into the results buffers at 25th beat and 20th beat respectively, now both results enter into THE SINGLE RESULT QUEUE at 25th beat. This change also forces that Dot product operation to use the Q1 hardware and entering also at beath 25th into the result queue, it could be done in an earlier beatt (in fact in the 19th) but multiplexation logic would have to be added. jguarin2002 4263d 09h /raytrac/branches/fp_sgdma/dpc.vhd
204 Working towards a DMA oriented RayTRac jguarin2002 4274d 22h /raytrac/branches/fp_sgdma/dpc.vhd
198 Check out for the best out for the best organization so the datapath does not consume to many logic cells jguarin2002 4291d 05h /raytrac/branches/fp_sgdma/dpc.vhd
196 raytrac+sg_dma+raytrac. Step One, the DPC is transformed. Now there are five instructions (check the design document), theres no full queue sync event, there are only four result queues and only 3 add fp 32 b adders rather than 4. Even it seems like a reduction has taken place, decodification efforts take place when decoding multiplexation from arithmetic blocks towards the resulting queues jguarin2002 4304d 17h /raytrac/branches/fp_sgdma/dpc.vhd
179 light change on code readbility for Datapath Control hardware description hdl file jguarin2002 4332d 01h /dpc.vhd
176 Little changes on full result queue signals codification in order to fix a potential bug that havent beed detected at the time of the change in the code jguarin2002 4367d 14h /dpc.vhd
175 Fixed a problem on the writing signal of results queue 5,6 and 7. The error was detected just right when a calculated normalized vector was about to be written in the results queues 5 6 and 7 and the write signals of those were not activated (it would remain in 0), after checking what was the problem, a codification bug was spotted. jguarin2002 4367d 14h /dpc.vhd
171 After some raytrac simulation result analysis, some bugs were detected on the decodification of several datapaths. Corrections were done and tested jguarin2002 4367d 15h /dpc.vhd
167 Corrections on the moment the dot product and normalization queues are "rd_ack\'ed", they were a cycle earlier than they should causing pipeline desync jguarin2002 4370d 05h /dpc.vhd

1 2 Next >

Show All

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.